perm filename TASK.RND[RDG,DBL]7 blob
sn#605139 filedate 1981-08-10 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00034 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00005 00002 ∂23 Mar 1981 1512-PST ROLANDA Protocol fle
C00046 00003 ∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
C00051 00004 ∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
C00053 00005 <READ THIS>
C00072 00006 ∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
C00085 00007 ∂6 May 1981 1552-PDT RICK bill's homework forwarded fyi
C00107 00008 ∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
C00128 00009 ∂13 May 1981 0653-PDT RICK Serious business
C00131 00010 ∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT>
C00142 00011 ∂18 May 1981 2355-PDT RICK Plan revisions**2
C00153 00012 ∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT> Revisions to CORE project plan thru end of FY 81
C00166 00013 ∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
C00187 00014 ∂15 May 1981 1331-PDT BILL revised plan with task assignments
C00204 00015 ∂TO Rick@Rand-Ai 15:38 20-May
C00217 00016 ∂21-May-81 0802 RICK at RAND-AI reply to your msg
C00240 00017 ∂To BARBARA@Rand-Ai 17:08 21-May
C00254 00018 ∂25-May-81 1407 barbara at RAND-UNIX Re: Relns connecting Rationale & PlanSteps
C00259 00019 ∂To: (%Rand-Ai Bill, Rick, Wescourt, Barbara, Norm, Mike) 17:24 29-May
C00305 00020 ∂29-May-81 0937 RICK at RAND-AI rll
C00315 00021 ∂29 May 1981 1322-PDT RICK Today's design contributions
C00327 00022 ∂TO Barbara@Rand-Ai 12:36 4-Jun
C00343 00023 ∂ 4 Jun 1981 1036-PDT Keith Wescourt <WESCOURT> Re: Comments on Keith's Proposal
C00345 00024 ∂19-Jun-81 1236 RICK at RAND-AI revised retrieval specifications
C00355 00025 ∂23-Jun-81 0647 rick at RAND-UNIX overall design and components plus interfaces -- discussion notes
C00359 00026 Discussion with Norm - 19 June 1981
C00368 00027 ∂TO Keith, Greiner (12:05 29 June)
C00370 00028 ∂29-Jun-81 1259 Keith Wescourt <WESCOURT at RAND-AI> Re: Data for Retrieval
C00372 00029 <reread>
C00380 00030 ∂24 Jul 1981 1112-PDT <WESCOURT> Re: Minor changes to Entry/Retrieval Interface Specification
C00391 00031 ∂TO Wescourt, Rick 17:05 24-Jul
C00399 00032 ∂TO Wescourt, Rick 18:25 24-Jul
C00406 00033 ∂TO wescourt at RAND-AI, rick at RAND-AI 14:24 29-Jul
C00421 00034 ∂TO Rick@Rand-Ai 13:39 10-Aug
C00425 ENDMK
C⊗;
∂23 Mar 1981 1512-PST ROLANDA Protocol fle
To: Greiner
cc: Rick
Russ,
Rick asked me to send this file to you:
1
2 mon feb 16 14:22:39 pst 1981
3
4 take either saturday or sunday.
5 the route:
6 pch to topanga cyn
7 topanga to mulholland
8 mulholland to lake vista drive
9 as soon as you predict you'll get too tired to return home,
10 return, or continue to:
11
12
13 lake vista drive down to the lake
14 return:
15 lake vista drive to mulholland
16 mulholland to topanga
17 lunch: eat at one of the places around the lake, lean up against bank
18 if you return prior to reaching lake, eat lunch at tapia park down las
19 virgenes 1/4 mile
20 north on topanga to dumetz
21 country club on dumetz which is novel to him
22 east on dumetz to serrana
23 north on serrana to ventura blvd.
24 east on ventura blvd to sepulveda blvd
25 back home
26 rose & walgrove (.5 mi east of lincoln) in venice
27 right near the sm airport
28 he says it's too long! needs shortening
29
30
31 plan escape routes
32 plan phone calls
33
34
35 ----------------------------------------------------------------
36 2/18 rationale
37
38 why the mon feb 16 plan was too long: based on comparison with
39 a ride that's closely related to this plan and which he's done before,
40 i.e. if you get rid of the side trip on mulholland and replace
41 topanga by old topanga. however, this trip might be too hard in current
42 physical condition of norm.
43 from 1, this suggests getting rid of
44 going up, old topanga is more difficult but infinitely preferable:
45 less traffic,more to look at.
46 amend the plan to go up old topanga, because of 3 and we know he
47 nice things to look at.
48 look for ways to amend the mon 2/16 plan to shorten it.
49 like the basic plan: pch through the mountains, down to valley,
50 and back via sepulveda. so going to change details within this overal
51 form.
52 some changes we can make:
53 a. shorten the part of the trip west of topanga to the lake,
54 by getting rid of that part of the trip.
55 b. would this be too long? no, he can't say that, but does
56 say it might be.
57 c. thus, let's cut out malibu lake and tapia park.
58 d. what things were these things trying to achieve?
59
60 at this point let's search the rationale for lake and tapia.
61 lunch place: tapia and malibu lake
62 urinating facilities: tapia
63 review the plan rationale for the part of plan
64 from pch to sepulveda for a lunch place.
65
66 for each piece of plan, check the rationale for lunch concepts.
67 lunch stop needs something nice to look at
68 lunch needs a natural or artificial back rest for sitting
69
70
71 regarding urinating:
72 almost anywhere on old topanga will do after you start to rise
73 add to plan to pee on old topanga after it starts to rise
74
75
76 norm is willing to take a plan that doesn't specify where to lunch.
77
78 so maybe the novel country club would be a good place to eat.
79 he's not averse to risk of this sort.,
80 but golf courses around here usually have fences around them.
81 this seems to eliminate the golf course for lunch.
82 boy scout camp on red rock road looks interesting. it's not a big
83 diversion. maybe it'll do for lunch.
84 keith's intuition is that there'll be a nice place to eat around
85 there and norm can lean up against a tree.
86 norm's never been on red rock road. it looks nice he says.
87 it is hilly.
88 patch the plan: let him go out on red rock road for upto 20 minutes
89 looking for a nice place to eat. if he can't find one, turn around and
90 stop near the country club somewhere for eating.
91 barbara recommends red rock
92 ever been on calabassas peak motorway? norm says motorways are unpaved.
93 for a few months, he's been unwilling to take unpaved roads.
94 is red rock paved? it has the same symbology on the 1971 ed of
95 thomas bros la street map as calabassas peak motorway.
96 if it's paved, it's a good idea. from the map norm believes it is
97 paved, but if it were paved, he'd know about it, and since he doesn't
98 know about it, he doubts it is paved. overall, he assumes it is partly
99 paved.
100
101 he'd be willing to go on an unpaved street for a short distance,m
102 but not down hill.
103 but since it's hilly, it'd have to be downhill at least one way.
104 how about walking to lunch? he's not averse to chaining the bike
105 to a tree. he is averse to walking more than 1/8 mile.
106 1/8 mi doesn't seem to be far enough to reach lunch on red rock road.
107
108 keith complained about the lack of relevant infor on the map for
109 the planning task.
110
111 lunch at dumetz: would it be too late? depends on the time the
112 plan starts.
113
114 9am would be a reasonable time to start.
115
116 if he started at 9, he could eat lunch at dumetz. it wouldn't
117 be too late.
118
119 at the intersection of old topanga & mulholland hiway, there's
120 a high school. they generally have fields, etc., and may make a
121 nice place to eat.
122
123 keith recommended eating at that high school (see 28)
124
125 barbara thought it wouldn't satisfy the seating or view requirements.
126
127 norm hasn't been to calabassas high school.
128
129 quite often high schools on saturdays are nice places to eat, e.g.
130 soccer games, etc.
131 on sundays, norm thinks they tend to be dull.
132 barbara says both saturday and sunday at paul revere junior high
133 things happen.
134
135 so they recommend the high school for lunch, and that means
136 the plan is restricted to saturday.
137
138 patch the plan to restrict it to saturday and lunch at the high school.
139
140 possible options fromthis point, after lunch:
141 can continue on old topanga from high school until it hits mulholland
142 and then go right and take it to topanga, or can
143 go back to mulholland hiway to mulholland drive and take that to topanga.
144 these roads define a triangle of about 1.25 miles on a side, and the
145 high school is in the center of that triangle.
146
147 work on getting him back:
148
149
150 sfv map shows greater detail on the triangle in 37.
151 the high school fronts on mulholland hiway, rather than old topanga road.
152 thus, of the two alternatives in 37, suggest that norm turn on mulholland
153 hiway rather than continuing on old topanga road.
154 at the intersection of hiway and old topanga road, norm should use his
155 judgment about the best way to get to the high school.
156
157 ventura blvd between serrana ave and sepulveda is not a pleasant ride.
158 what about streets that are deeper (more north) in the valley for
159 more pleasant ride.
160 what about victory, which is 2 mi further north. less cars, good.
161 smaller shoulder than ventura.
162
163 oxnard is nicer. good things to look at and nicer than
164 ventura or victory, as in 40.
165
166 patch to plan: from serrana, continue across ventura by joggin
167 to right onto de soto, under the ventura fwy. take de soto to oxnard st.
168 right on oxnard. oxnard to tampa ave, left on tampa, right on topham st.
169 topham to white oak. topham changes names back to oxnard st.
170 continue on oxnard st to louise ave. right on louise, lousie to
171 burbank blvd.
172
173 how is burbank blvd, where it goes through the sepulveda flood
174 control basin? norm doesn't know.
175
176 44contd. turn left on burbank blvd to sepulveda blvd. cross under
177 405 (or under). right on sepulveda, go south.
178
179
180 presumably sepulveda blvd is the only way back at that point other
181 than the freeway.
182
183 there are many ways from valley up to the top of the hill
184 (the santa monica mtn).
185
186 havenhurst/calneva, a couple of miles west of sepulveda,
187 is an interesting way from the valley up the hill.
188
189 patch the plan: louise to burbank to sepulveda gets changed
190 to... right onto havenhurst from burbank. havenhurst across ventura
191 blvd, uphill, until calneva. left on calneva. calneva to mulholland
192 drive. left on mulholland to sepulveda, then south on sepulveda.
193
194 can't get directly from mulholland to sepulveda; they don't
195 intersect.
196
197 oxnard is only .5 mi north of ventura, so the oxnard detour
198 adds only 1 mile. it's completely flat, and will probably be less
199 wear and tear than riding on ventura bl.
200
201 start working on best way back from sunset & sepulveda to home.
202 bundy and centinela are bad: narrow, no shoulder, lots of traffic.
203
204 suggest: right on sunset from sepulveda
205
206 sepulveda south of sunset has no traffic but no view either.
207
208 ohio has a bike path.
209
210 patch: sepulveda, right on ohio, left on barrington.
211 barrington to gateway, right on gateway to
212
213 must get around sm airport, two possible ways.
214 bundy or ocean park or pearl st are alternatives.
215
216 redo 56
217 patch: sepulveda, right on ohio, left on barrington.
218 barrington to gateway, right on gateway to
219 ocean park, ocean park to 21st, lefton 21st,
220 continue to dewey st where he makes a left.
221 norm considers this home.
222
223 big problem with the plan is calneva, it's too steep,
224 given the amount of other things going on,.
225
226 to avoid calneva, you don't want to go on the south side of
227 ventura.
228
229 norm denies 58,but keith says it would take lots of street changes
230 to do, and norm previously said he didn't want to have to handle complicated
231 plans. that's why 58 is the way it is.
232
233 patch: south on havenhurst, left onto ventura blvd, go approx 1 mi
234 to haskell avenue, right on haskell and it will eventually turn into valley
235 vista, and thence to sepulveda.
236
237 going south on sepulveda from that general vicinity, it's
238 better to get off burbank before crossing havenhurst otherwise you'll
239 have to go through lots of freeway underpasses and add distance.
240 inferring that there'll be traffic near freeways, freeway exits, and
241 oxnard is near the freeway around there.
242
243 in generally, there's a tension between simplifying the plan to
244 lots of turns etc vs. minimizing traffic.
245
246 biggest current problem is going up topanga from ocean on saturday
247 morning when there's lots of traffic coming to the beach.
248
249 in norm's present condition, there's no way other than topanga
250 up to that part of the mountains without going out to malibu, which
251 is too far west.
252
253 basic conflict: up topanga on saturday is unacceptable; lunch at
254 high school on sunday, would be acceptable assuming he can get in.
255
256 patch: switch the plan to sunday.
257
258 the current big problems:
259 need to provide for rand stop
260 provide for equipment malfunction
261 provide for water along the way
262 not enough plans for urinating along the way
263
264
265
266
267
268
269 patch in plan: topanga to old topanga, old topanga to mulholland
270
271
272
273
274
275
276
277 hiway, east back to topanga canyon, north to dumetz, then as per 2/16
278 plan.
279 lake callabasas doesn't exist as far as norm knows
280 considering sending him up old topanga to lake callabasas to shorten the
281 trip
282
283 ---------------------------------------------------------------------
284 2/16 rationale
285 there are urinating facilities at tapia park
286 limit a ride to 6 hrs total elapsed time
287 the length of daylight constrains the trip, wants to go in daylight
288 the ideal temperature is 60 degrees
289 temperatures below 90 is okay
290 even 40- degrees at low end is okay
291 speed is 10-15 mph on flat surface, including traffic delays
292 we derived his speed up mandeville cyn road is 7.5 mph
293 he's not in the best of shape right now
294 all these things led us to a round trip of around 45 mi
295 tuna canyon has been closed for two years, and it's too steep
296 piuma climbs from las virgenes to rambla pacifica
297 rambla pacific is very steep for descent, too steep if the rest of ride
298 was hard
299 lunch stop needs something nice to look at
300 lunch needs a natural or artificial back rest for sitting
301 urinating needs a restroom or not too public place
302 nice beach day, pch from malibu to santa monica is unpleasant due to
303 traffic from surfboarders, in afternoon
304 on non-sundays, topanga has excessive traffic
305 theorem: getting back from santa monica mountains on the weekend requires
306 an inland route to avoid these conditions
307 doesn't like descending topanga canyon in traffic because it's grueling
308 steep descents require resting places periodically (not topanga, but
309 rambla pacifica)
310 tuna canyon was steepest grade in west la county
311 good view at mulholland and malibu canyon (purple cows)
312 lunch place: tapia park below mulholland
313 lunch place: malibu lake
314 dirt roads are out, unless very short
315 doesn't like riding in flat places, such as san pedro
316 coast bicycle path has too many pedestrians et al in the afternoon
317 he likes hills
318 6am in the morning is too cold in this season
319 map distance measurer is 4.4 mi per inch on the la & vicinty map according
320 to kw's calculation
321 coast hiway to malibu from sm is perfectly flat
322 in his current condition, he doesn't think he can do the whole trip
323 which was rand to topanga, to mulholland, to malibu cyn, and
324 back through valley.
325 but the trip was generally nice anyhow
326
327
328 -----------------------------------------------
329 2/20
330
331 coast hgh to top to old top to calabassas hs to mulholland to
332 top to dumetz to serrana jog to right to desoto
333 north to oxnard east to topham=oxnard right on whiteoak
334 left on burbank to havenhurst left on ventura right on
335 haskell=valley vista right on sepulveda...
336 sepulveda, right on ohio, left on barrington.
337 barrington to gateway, right on gateway to
338 ocean park, ocean park to 21st, lefton 21st,
339 continue to dewey st where he makes a left.
340 norm considers this home.
341
342 the current big problems:
343 need to provide for rand stop
344 provide for equipment malfunction
345 provide for water along the way
346 not enough plans for urinating along the way
347
348
349 norm: if i go north, must stop at rand either coming or going
350
351 norm: early in am must urinate more often; cannot wait until old topanga
352
353 norm: where to urinate aftyer old topanga--need one more
354
355 norem: need to stop to wash once, depending on how hot
356
357 norm: carried water too prescious to wait on hot days
358
359 norm: might not be hot in near future
360
361 rick: been hot last few days
362
363 norm: wash stop also necessary to refresh water bottle
364
365 norm: one water bottle on cool day, more on hot day
366
367 if can fix bike myself (e.g., flat tire) need time to
368 fix and get home before dark
369
370 if cannot fix myself, may be immobile
371 for going up
372 for going up or down
373
374 try to plan route with only one steep uphill
375 can push bike up one mild uphill
376 walking is hard
377 route too far to walk all the way home
378 bicycle could be fixed at bike shop if near enough
379 can call for help
380 can't call from san fernando valley
381 wife can't drive that far--too far
382 but she could come if absolutely necessary--very unlikely
383 must be coordination with wife for emergency calls
384 daughter drives, but have never used her
385 3-4 bicycle shops on ventura between top and sepulveda
386 some shops on sunday
387 phone book at every phone booth in valley
388 many phone booths on ventura
389 can coast downhill from mulholland & top to top & ventura
390 if chain breaks, can get to coast highway
391 most frequent malfunction- flat tire, fix myself
392 carry spare tire, 2 spare tubes, pump
393 takes half hour in dirty clothes to change tire, longer in clean cloth
394 norm knows route time from experience
395 this route takes 3-4 hours, not including stops
396 prefers 2 hours rest
397 worst thing would be getting hit by car
398 precautions too detailed to worry about
399 most likely problem that could add delay: flat tire
400 next: too tired to proceed safely
401 or non-repairable equipment malfunction (e.g., broken chain)
402 chain has broken 4-5 times
403 doesn't carry universal link because doesn't know how to
404 take apart chain right, tried once and broke it
405 gear shift cables can break
406 doesn't carry spare cables because can't/won't fix self
407 normally just adjust mechanism so remains in low gear+>
408 get home, but slowly
409 carry screw driver, wrench, tire iron, etc.
410 break cable broke once
411 couldn't gop down topanga or ride bicycle without break cable
412 above suggests need bike shop on valley side of hill
413 under plan, would never be more than mile away
414 on sunday, 4 miles between top & sep => could be further
415 norm suspects 3-4 miles
416 he would walk
417 15 minutes to walk mile => 1 hour to walk 4
418 only thing worse is handbreak breaking
419 norm: highly unlikely and would call for help
420 takes bag full of dimes
421 rick wants norm to take nickels and quarters in case dime slot jammed
422 longest current stretch with no phone is not too long
423 longest (time) stretch with no potty is from house to beginning
424 of unsettles old top (1.5-2 hours) at difficult time of day
425 therefore, should go to rand on way out
426 can pee at rand
427 can pee at public potty on coast highway
428 norm always carries catheter
429 needs to pee after lunch--at school
430 school is not far from ventura
431 needs to refill water bottle in case hot day
432 can stop at gas stations to fill bottle if open
433 they close on sundays
434 there is a restaurant intersection vent and topo open on sundays
435 too far? no it's all downhill
436 must lock bioke to go in restaurant
437 patch plan: pee at vent/top restaurant, get water, fill bottle, clean face
438 if hs yard open, might have fountain for splashing, etc.
439 hs yard might be closed on sundays
440 it's a county school
441 might have field open
442 norm won't climb fence
443 needs second source of water in case hot day
444 never has run out of water on way up old top
445 always fills water bottle before goes up
446 can fill it at beach potty
447 patch plan: fill water bottle at beach potty
448 needs to pee after top/vetn at least once near sepulveda
449 many gas stations near there
450 prefers not to pee in gas stations
451 not many places on sepulveda where can pee
452 many public parks where can pee
453 parks better than gas stations for peeing
454 gas stations are incredibly dirty
455 prefer not to touch door handle in gas station
456 plan patch: when on burbank, stop at sepulveda recreation area too pee
457 norm wants to take a side trip to the model airport
458 he prefers watching female roller skaters over male model fliers if hot day
459 need potty this side of mountain...just in case
460 va cemetery has nice potty--immaculately clean
461 time estimate
462 3-4 hr for bicycling
463 2 hr side trips and rest, including peeing
464 1 hr to walk to repair shop
465 1 hr for repair
466 2 hr for repair shop enough for self repair
467 max elapsed time = 8 hours +← stop at rand = 1 hr or less
468 max time = 9hr
469 est is too long
470 once reach bottom of hill on sepulveda, if it's too dark can call wife
471 earliest come to rand=8
472 best time to leave rand & start current trip depends on temp
473 plan patch: arrive at rand 7:30
474 because it's cold in morning, don't want to start too early
475 earlier better, but not if too cold
476 want to leave time for other things
477 depart rand by 8:30
478 1 hour more than enough & want to get on road as soon as poss.
479 reach hs no later than noon
480 whole trip only takes 3-4 hours
481 if doesn't reach halfway point by 3 hours, something wrong
482 reach vent-sepulveda by 3
483 3 hours for third of trip + lunch is plenty
484 if don't get there in time, stuck
485 correction: vent/sep by 4
486 because if all goes well takes 2 hours to get home from there
487 dark by 6:15
488 if doesn't get there by 4
489 can't call naomi or walk
490 doesn't know if daughter will be home then
491 could but rarely takes taxi
492 rick won't be there 2/22
493 nothing like this has happened before
494 norm would call naomi & ask her to find someone else
495 otherwise taxi to sep&sunset
496 arrive home by 6
497 if fall behind schedule on this side of mountain, return home
498 if fall behind on that side,
499 do not take trip if rains
500 if rick picks up norm, he should pick up faucet
501 norm will take care of clothes and newspapers
502 clothes must suit weather
503 if cold before 9, take newspapers because disposable
504 norm doesn't know what naomi is doing any sunday
505 patch plan:
506 coordinate to reach naomi at 3 or 4
507 norm believes can do
508 be at phone at 3 or 4
509 should know by 3 if falling behind 4 deadline
510 assume, with no malfunction, will reach sep & vent by 3
511 assume, with malfunction, will reach sep & vent by 4
512 if above fails, take taxi to whatever point necessary to get home
513 take $20
514 will cover taxi fare
515 but may need more if repairs
516 usually carries only dimes & credit cards
517 take $50
518 he doesn't want to
519 take $20
520 what if it rains during trip?
521 doesn't carry rain suit
522 doesn't have suitable one
523 usually, if it rains, he takes easiest route home
524 can't really ride in rain suit
525 gortex would work
526 doesn't want to spend money on gortex
527 problem trivial compared to hand break not working when wheels wet
528 riding in rain in certain conditions unacceptable for long period
529 rain is problem only in afternoon, after 4
530 unlikely to forecast rain
531 rick thinks forecast overestimate rain chances
532 norm would go if chance of hard continuing rain at top of topanga = 5-10%
533 this is worst possible rain
534 norm won't go with any chance of rain
535 rain info from weather service -- not reachable when rain predicted
536 flight service provides useful info only 10% of time
537 patch plan: go only if 0% perceived prob rain
538 norm doesn't want to get wet
539 norm doesn't want to ride down top with wet rims
540 patch plan: norm will plan tactics
541 need route sheet
542 patch plan: night ahead, norm should prepare route sheet
**************
Rolanda
-------
---------------
-------
∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1238-PST
Russ:
We may eventually constrain, a little but not greatly, the form of the
users' input away from free-form english. We are even considering parsing it
using a good general parser. However, you're on the right track to
think about scanning the input to build conceptual (what you called "keyword")
tags to hang on the sentences. Your task is to enable conceptual labeling,
with arbitarily interesting sources of matching between input and
concepts. To do this, you need to develop a language for describing concepts
and the ways they are realized in inputs. This is different from parsing, in
general, because each distinct user group will speak a different "language"
and will need to emphasize different concepts.
For example, you might want to develop some concepts related to
preferences. Norm has preferences for certain kinds of things and against
others. The relationship between a thing and norm's preference for it
often is the basis for it being included or excluded in the plan. We
need a way to succinctly express such a relationship and have it recognized
in the input so it can be stored and matched (with other inputs, called queries,
which also exhibit it).
Another example, we had something in the concept taxonomy that
barbara prepared having to do with "interesting." However, when we had
a replanning session focused on "make a new route for norm which is changed
as little as necessary but which is less boring than simply repeating the
same route would be," the guy wanted to find anything about "boring" but
couldn't. Find x such that x bores norm is the query. How should we find it?
How can we insure that if it's there, we will actually find it. How can we
express heuristically defined alternative queries that we think will satisfy
the retrieval goal? How should we retain these definitions? Should all
of these automatically be processed for each input and stored with it for
subsequent matching?
e.g., Norm thinks x is dull => x bores norm
e.g., Norm thinks P => interesting but }P(x) , thus is x un-interesting?
e.g., Interesting (x) => }boring (x)
e.g., Tacit: more familiar => more boring & more recent => more
familiar
I hope this gives you enough grist to move on.
My image of what you're producing is a front-end to RLL to let me build
my own conceptual definitions easily; a matching method that finds instances
of concepts in inputs; a matching method to find stored things that
correspond to coneptual descriptions; and a method to extend or rectify
conceptual defintions in light of errorful performance or new desires.
Push on!
Rick
-------
∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1318-PST
I'll send you a more detailed problem statement for the project before
leaving for this weekend. Then, I'd like to have you down at rand in
the first week of may to attend a planners' pencil planning meeting.
Either weds or frid would be best. I expect the stuff you are doing
will get along fine for three weeks without direct interactions.
Let me know if you feel otherwise.
Cheers,
Rick
-------
<READ THIS>
∂16 Apr 1981 1004-PST RICK Planners' homework 16-apr-81
To: bill, greiner, wescourt, barbara at RAND-UNIX, norm at RAND-UNIX
cc: rick
Here's my entry:
0<RICK.PLANNER>PENCIL.HOMEWORK.1 10-Apr-81 10:23:16, Edit by RICK
The question: Is the pencil better/worse/potentially better than
using the protocol?
Answers:
BETTER:
> because it identifies early what the planners wound up believing,
rather than their initial or intermediate ideas
> because it helps answer questions about hypotheticals the replanner
comes up with
> because it identifies the many ways one decision supports others
> because it tells the replanner why some currently considered
alternative was previously rejected (and usually is still bad)
> because it saves time in rejustifying unchanged parts of the plan
WORSE:
> it fails to establish a coherent picture around each idea, since
the units are atomic, the pointers bring in clusters, but most
trains of thought are linear when being developed or absorbed
> currently, the replanner needs to absorb and organize mentally the things
kludge spits out at him before he can deal with them
> thus, although the plan rationale is structured, the structure
used doesn't help him solve his problem
> data get lost and mangled from protocol to items file
> the process is hard, unsystematic, error-prone
> the uniform & simple type of rationale structure with a list of
pros & cons can't convey which of the supports was most influential,
which least, etc., but conveys the misimpression of equal importance
POTENTIALLY BETTER:
> if it provides a linearized readable explanation of why choices were made
> i would like to see a "movie" of the evolution of the plan,
what Keith called the rationale for the rationale
> if it provides a linearized set of alternatives for each choice and
makes it easy to see the pros and cons of each
> if it organizes the plan into a hierarchy of subplans,
the rationale into a hierarchy of goal-achievement proofs,
the assumptions into a hierarchy of inherited assumptions informing each
phase of planning (hence some temporally related collection of
plan rationale parts),
the alternatives for each plan element with their corresponding effects
(goal/constraint attainment/failure)
> if articulation were systematic
> if people could find the answers to their questions
HOW TO IMPROVE THE EXPERIMENT
> make the replanner autonomous
> make the items in the rationale self-explanatory
> give the replanner software training and clear instructions
> use ourselves as subjects rather than others
> divide into two groups then transfer to the others' problems
> take a part of the planners' workbench as the task
> prescribe replanning strategies
> build abstractions into the plan & rationale
-------
Date: 16 Apr 1981 1008-PST
From: RICK
Subject: test of planner mailing list
To: wescourt, bill, greiner, randvax!norm at RAND-UNIX, randvax!barbara at RAND-UNIX
cc: rick
only tell me if you don't receive this please where you want it
-------
Date: 16 Apr 1981 1037-PST
From: Keith Wescourt <WESCOURT>
Subject: Homework
To: Planner: ;
QUESTION:
Is our current system, KLUDGE, for describing plans better
than a raw protocol?
Before considering the pros and cons of Kludge vs the protocol,
I think it is important to note several facts:
(1) The protocol we have is a very poor one relative to what a
protocol could be. Not that we did try hard, but the coverage
and detail suffer in comparison to what a trained stenographer
could have captured. Therefore, the limitations of the present
protocol may not all generalize and its strengths may have the
potential for further enhancement.
(2) However, if the protocol were more detailed, it would also be
longer and thus less manageable. This would be aggravated in the
protocol of planning sessions for a more complex problem.
Therefore, comparisons of the current protocol with Kludge depend
on the extent of this particular exercise and may not generalize
to smaller or larger scale planning.
(3) Since, the database we used in the current exercise with
Kludge was almost entirely based on the protocol, the use of
Kludge inherited some of the defects of the protocol.
PRO the PROTOCOL:
(1) The obvious: the protocol contains more information. We got
most of the facts and reasoning from the protocol into the rationale
items, but there is other transitional information-- e.g., statements
of questions raised by group members-- that provides context lacking
in the rationale database.
(2) In general, the protocol better conveys some aspects of the
structure of the rationale for plan steps. First, in the protocol you
can see whether a plan step was determined by a generate-and-test
method or by a specify-and-search method. By generate-and-test, I
mean that a tentative plan step was initially generated from a single
goal/contraint; for example, it is a route segment that connects two points
the planned course should reach. That plan step is then "tested" by
an attempt to generate rationale that supports the conclusion that it
satisfies/does-not-violate other goals/constraints. Specify-and-search
on the other hand, involves first stating a rationale involving
multiple goals/constaints and then looking for plan step consistent with
that rationale. Too much shouldn't be made of this distinction, since
the two techniques chain together; it is probably better to think of
a general split of rationalizing that takes place before or after a
tentative plan step is generated. I think the importance of knowing
this distribution for replanning is that it helps indicate the
likeliest ways to change plan steps without perturbing other parts of the
plan. For the most part, it is easier to change plan steps along
lines that have to do with the rationale following a plan step
determined by generate-and-test.
(3) Even if you don't believe the preceding claim, there is a more
general advantage of having the temporal information in the protocol.
The order of rationale development for a plan step conveys which
assertions were most critical for supporting or rejecting a conclusion.
In fact, the complexity of the trade-off between the pros and cons
for a plan step is much more obvious. Thus, in replanning, if one has
the protocol it is easier to see which goals/constraints it is most important
for modified plan steps to satisfy.
(4) The protocol better shows the evolution of the plan. You not only
know which plan steps and rationale are in and out, but when they
went in or out relative to other plan steps. Knowing this dependency
information allows one to use some simple heuristics about which
changes during replanning are least likely to interact with the
remainder of the plan.
PRO KLUDGE and its rationale database.
(1) The obvious: once you have a feeling for the Gestalt of the
problem and the concepts/vocabulary of the rationale database, it
is much easier to retrieve items about specific concepts and to
trace the full set of assumptions underlying the acceptance or exclusion
of a plan step. For simply searching, the Kludge software is much
superior to examining the protocol, even if one has the protocol
in a regular editor and can bounce around looking for strings.
In addition, the rationale file provides a much more explicit representation
of the arguments that the raw protocol. As the raw protocol progresses,
assumptions for similar types of arguments are often not repeated.
Unless one has very comprehensive mental picture of the entire
protocol, then it is easy to miss that a plan step has some rationale
that is not articulated in the protocol at the point where the
plan step is proposed. The coding of the rationale items and their
relationships made all the implicit rationale explicit for Kludge.
(2) While the protocol seems better for seeing which assumptions/assertions
are most vital to deriving a specific plan step, Kludge is much
better for determining which assumptions/assertions are vital because they
are involved in the derivation of several seemingly disjoint plan steps.
Thus, for example, during replanning, if one is contemplating a change
to a plan step that would cause a goal or constraint to no longer
be satisfied, then one can easily check (via ramify) whether there are
remaining plan steps that still satisfy it and thereby make the
proposed change acceptable (e.g., if you want to change a route segment
that has a potential water stop, you can check to see if the
adjacent route segments have alternative water stops in their supporting
rationale). To summarize, Kludge is better than the protocol for
determining those relationships between rationale and plan steps and
between plan steps that are not tied to the temporal structure of
the planning process (and protocol).
RECOMMENDATIONS
(1) It might be worth considering whether one wants to view protocols
and Kludge-like software are mutually exclusive. They seem to have
complementary features. Besides, for the foreseeable future I see
no way of going from planning to encoded rationale without a protocol,
unless we determine that planning must be done in a structured environment
which includes rationale elicitation. There are problems with keeping
protocols around, however. They are long, especially if they are
properly recorded and if they are for problems of greater scope than
the one we considered in our exercise. Reading the protocol may thus
be costly and less effective for the replanners.
(2) I see a couple of alternatives for improving Kludge to provide
the information one can get from the protocol. As long as a protocol
is around, I see the simplest alternative to be adding pointers from
encoded rationale items back the protocol and providing a way
within Kludge to retrieve the actual protocol text from which encoded
plan steps and supporting arguments were drawn. In a sense we have this
in a rudimentary form now, because most of the item names reference
lines in the protocol; one can therefore go from Kludge output back
to the protocol to selectively review the full context of rationale.
However, this is clumsy. I can easily see protocol pointers in each
rationale item that allow the user to jump into an editor/scroller
at the proper place in the protocol to more fully explore a bit
of "raw" rationale. A second, harder alternative would be to directly
encode the temporal structure of rationale into the encoded rationale
database. This might include adding temporal pointers between the
items used to rationalize a plan step or another rationale item (for
multi-level rationales). It might include annotating each item with
a "priority" tag indicating it's degree of importance in a particular
argument. Representing this additional knowledge may not be very easy,
particularly for items that appear in multiple arguments. In addition,
representing changes in the importance of an item within a rationale
over time would be hard I think. In general, I guess what I see as
necessary is a full history mechanism for representing not just the
final role of each item in the encoded rationale, but a representation
of its role at each point during the evolution of the plan. I claim
that such a history may not be particularly important for verifying
whether the paln is still valid before executing it, but is very
important for replanning to keep the replanners from duplicating
errors the original planners already recognized and eliminated.
-------
∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
To: bill, randvax!norm at RAND-UNIX, greiner, randvax!barbara at RAND-UNIX
cc: rick, wescourt
Folks:
Here is my cut at the project-plan. When time permits,
I will encode it into a plan rationale.
In the meantime, read it, digest it, ponder it. Guide your
behavior so that it's in accordance with the plan thrust or initiate
plan changes.
We will meet 1:30 Friday May 8 to discuss the eventual form of
this plan.
I hope it suits you. It attempts to reflect your interests
and strengths, but it's just an initial guess at those.
Rick
----------------------
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
∂6 May 1981 1552-PDT RICK bill's homework forwarded fyi
To: barbara at RAND-UNIX, greiner
cc: rick
∂6 May 1981 1538-PDT BILL workbench.todo homework
To: rick
cc: norm at RAND-AI, barbara, wescourt
Additions to my copy of WORKBENCH.TODO are indicated below by ":>"
in lieu of ">". The suggestion that we (1) anchor what we do at one
end with protocols and rationale and at the other end by standard
planning tools, such as Gantt charts, and (2) use a Rand management
plan other than the workbench plan for the demo.
WORKBENCH.TODO
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
:> Usable by some specific group of planners
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
:> Usable by some specific group of planners
:> Group other than the core group
:> Much greater credibility among potential users/clients
:> Broaden the base of planning inputs to workbench design
:> Not much harder to do than demo based on workbench planning
:> Doesn't preclude using workbench for workbench planning
:> Management planners
:> Structure of management plans is well-known and fairly well
standardized
:> At the highest level, output should be practically identical to
planning output presently used
:> Highest level output should be in form of Gantt charts,
manpower utilization charts, and (possibly) critical path
networks
:> Identical-to-normal output makes planners comfortable,
feeling in-control, and makes any use of workbench entirely
voluntary--hence no opposition to workbench
:> Identical-to-normal output is immediately and unquestionably
useful and usable
:> Presently used planning methods have limitations workbench could
help overcome
:> Changing dates means redrawing charts; graphic capability to
do this would be welcomed
:> Shifting resources impacts several planning tools/displays;
modifying the workbench database could kill several birds with
one stone and assure consistency among plan parts/displays
:> Presently used methods entirely devoid of supporting rationale
:> Keeping plan current is often considered not worth the effort;
challenge to workbench would be to make plan maintenance
worth the effort
:> Management support is needed to fund workbench research;
management is already familiar with strengths and weaknesses of
current management planning; easiest demo for funders to relate to
:> It is essential that the program/project manager personally want
to use our highest level (identical-to-normal) output in managing
:> In-house Rand planners
:> Would facilitate close liaison between planners and workbench
researchers
:> Possibly ICJ research program planners
:> ICJ would probably benefit from improved planning
:> ICJ has to replan as result of revised funding and outcomes
of research projects
:> Rationale for ICJ research is complex, hard to untangle,
easy to lose sight of as things change
:> To the extent that ICJ is using some AI (Waterman/Peterson
work on modeling legal systems using ROSIE), there is some
sympathy with AI applications
:> Bill thinks Steve Carroll might be receptive to the idea,
possibly partially funding Bill during the summer to implement
it
:> Demonstration of workbench being a demonstration of ICJ
management planning might, in itself, be useful to ICJ, for it
to use as a demonstration, showing synergism of ICJ with Rand
:> ICJ not military--drawback from ARPA perspective
:> Possibly Strategic Assessment Center planners
:> SAC currently expects funding for June-September on-board in
June
:> SAC has already gone through several replanning phases; more
to be expected
:> There are divergent views on what SAC should be doing
:> Divergent views within Rand
:> Divergent views among clients
:> Workbench could help sort them out; help tailor briefings
to specific audiences
:> SAC has some sympathy with AI applications, using game-playing
in Red/Blue agents (Gillogly) and ROSIE heuristic modeling in
Scenario agent (Dewar/Schwabe)
:> Demonstration of workbench being also a demonstration of
SAC management planning might, in itself, be useful to SAC,
for it to use as a demonstration
:> SAC military--advantage from ARPA perspective
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: identify planning/replanning output that
(1) could be produced by workbench
(2) would be on 8 1/2 x 11 inch paper
(3) would be nearly identical to planning output
planners would use without workbench
(by end of July)
code software to prepare the above identical-to-normal
planning/replanning output from workbench-produced files,
using software existing on VAX as much as possible
(August-September)
elicit SAC planning/replanning items and rationale from interviews
and existing memos; work with other core group members getting
rationale into proper form
(May-June)
elicit ongoing SAC planning/replanning information
(July-September; possibly SAC funded)
help identify capabilities that would be useful to management
planners in linking task plans, resource plans, and research plans
and that the workbench (demo version or subsequent version) could
provide; develop and maintain a "wish list"
(May-September)
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
0<WESCOURT.PLANNER>PROJECT-PLAN..5 8-May-81 13:17:32, Edit by WESCOURT
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
KW's Notation:
/kw == kw's rationale statements
{kw: ....} == kw's questions and suggested revisions
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
/kw searching for raw strings is inadequate
/kw conceptual structure must be accessible to encoder & retriever
> Easy conceptual extension
/kw encoder & retriever will develop new useful conceptual distinctions
as the workbench is used
/kw it is impractical for users to manually attach new conceptual
knowledge to existing items
> Good plan rationale entry, especially proof construction
/kw users cannot be trusted to enter consistent structures without
without aiding
> Some graphic display
/kw we believe that graphics are necessary to make stored rationales
understandable
> Some graphic editing
/kw given graphic display, graphic editing is a natural medium for
changing stored structures
> Reasonably complex problem
/kw outsiders won't be interested with successes on toy problems
/kw we want to work on something meaningful to us
/kw a complex problem is needed for us to discover the important
issues in building and using a workbench
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
/kw origin of plan contents and knowledge of plan evolution are
important for understanding and evaluating it-- they supply
additional, implicit rationale
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
/kw each person has some different skills and interests
/kw the rand environment stresses individual accountability
/kw we think we will be more productive by subdividing responsibility
> Each specifies what he/she wants to produce
/kw this will make division of responsibility more meaningful
/kw we think we should be able to pursue our own interests within
the context of the project
> Collaboration to integrate designs
/kw given division of responsibility and individual choice of direction,
negotiation between individuals is essential to build a working
system
> A usable tool
> Viable, friendly, moderate speed and size
/kw the system must make a good impression on outsiders who use it
/kw we won't enjoy working with a slow, clumsy-to-use system
> A good self-contained demo & tutorial
/kw we don't want to be burdened with personally acquainting people
with the system
/kw people are impressed by systems that they can understand and learn
to use without hand-holding
/kw a system is not complete without documentation
> Complete our Kludge experiments by June 1
> Rerun the experiment
/kw we don't feel we learned enough from the first experiment
/kw the software wasn't adequate for the first experiment
/kw we think we can do better the second time around
> Run the experiment on ourselves
/kw we all need to know how to use the software well
/kw we all need to be able to appreciate the system from the
users' point of view
/kw we all need to understand the cognitive/emotional aspects of
trying to do disciplined replanning.
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
/kw we are shooting for a Oct 1 demonstration
/kw we already have a set of objectives we know we cannot fully
satisfy by Oct 1
> Define a useful example
/kw we think that we cannot yet create a problem-independent
workbench so we need have the application clearly in mind as
we develop this prototype
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
/kw preprocessing will make retrieval faster at run-time
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
/kw we can't support arbitrary questions
/kw we think we have identified the most useful/frequent types
of questions
> Allow a flexible language for describing patterns of both
conceptual and string matching
/kw the conceptual hierarchy will probably not be sufficient by
itself
/kw the user will be able to access the database and identify
raw strings useful for search
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches {kw: what does this mean?}
/kw we should support sysntactic as well as semantic variations
> Easy conceptual extension
{kw: this seems like it will be tricky with preprocessing}
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
{kw: How about using interactive menus driven by "planning grammars"}
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
/kw it is tedious to manually replicate the same structure for
several different plan steps
> Need implicit satisfaction of constraints by all actions
{kw: I'm not sure what this means}
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
/kw representation of some things by exclusion rather than inclusion
has certain advantages
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
/kw we think people generally want to limit or at least control the
level of detail they must see at any time
> Varying attributes/dates/designations of items => varying symbols
/kw people need powerful simple ways of distinguishing classes of
information
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
/kw emergency replanning is a very motivating problem for most people
at Rand
/kw we could all feel like we were contributing to society
/kw emergency (re)planners need and WANT help now
/kw emergency planning organizations seem to lack some features
we feel may reduce the effectiveness of the workbench for
other organizations (e.g., the tendency to hide reasons from
others)
> A military one
/kw there is a lot of military expertise at rand
/kw the DoD is paying for this research right now
/kw the military needs planning help
/kw ~ it's hard to get access to military data for real,
interesting problems
/kw ~ most of us would rather not work on classified problems
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
{kw: tutorial, too. I see the order/priority of my tasks to
be question-answering; paln evolution; tutorial}
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
{kw: >> menus}
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
{kw: >> menus}
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
-------
∂13 May 1981 0653-PDT RICK Serious business
To: wescourt, bill, greiner, norm at RAND-UNIX, barbara at RAND-UNIX
cc: rick
Folks:
I have asked several times for you to submit
revised overall project plans to me as well as developing
specific areas of responsibilities and tasks within your
chosen area of responsibilities. I have stated that this
is the highest priority for the project!
I am concerned that this task has not been done well
by any of you yet, and until it's done well by everyone
we can't proceed to the next (and really critical step)
of ratifying a consensus plan and then implementing it.
Therefore: please stop whatever else you're doing on
this project and work exclusively on comprehending,
refining, elaborating, and respecifying the proposed
plan I gave you 4WEEKS AGO! Do not charge any time to
this project between now and monday for anything other
than this task (unless you have previous project-specific
commitments; but don't make any others).
I am very serious about the importance, primacy and
urgency of this task. I consider it unfortunate to have
to act so directively with respect to this, but I have
run out of patience with the normal (slow and casual)
manner in which people have approached this planning task.
Monday, when I return from DC I'll attempt to integrate
the revised plan suggestions and move us quickly toward
a specific set of tasks and schedules. I wish this weren't
necessary--(one of the things you might suggest revising
if you have a better plan)
Have a good time: this really should be a fun
task (even if it seems to be rammed down your throat).
See you next week,
Rick
-------
∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT>
Revisions to CORE project plan thru end of FY 81
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
GENERAL GOALS/CONSTRAINTS
[Rick]
Consolidate and package our efforts to date. If we find the project
is not to be continued, what can we present to the AF and the world as
our accomplishments.
{
We have a responsibility to the AF.
We want to be able to coherently describe what we've done to
colleagues.
We MAY need it to help secure further support.
}
[Rick]
Secure support for further work.
{
We want to continue the project.
}
[Bill, Rick]
Associate the project with a real-world planning task either internal
or external to Rand, but external to our own immediate self-interests
(it can affect us, but should be someone elses problem and
responsibility).
{
Such a problem will motivate us to do better work.
Such a problem will give the project credibility and visibility that will
enhance its prospects for having a real outcome and our own
careers.
}
[Rick]
Maintain the productivity and happiness of project staff
{
Promote the cohesiveness and stability of the project.
Increase the likelihood that the project will generate something
worthwhile.
Satisfy the personal goals of project staff
}
GROUP ACTIVITIES
[June 15, Rick]
Articulate a motivation for what we are doing that anticipates the
questions we have had directed at us in previous briefings and
discussions. Each staff member must learn that entire motivation.
What is the problem?
Why do we think a primarily technological solution can solve
it?
Even if we can generate a solution, why do we think we can get
anyone to use it?
{
We need to be able to determine whether our efforts are making any
progress.
We should share a common perspective on what we are doing.
Everyone should be able to brief the project to clients/visitors.
}
[?date?, Norm]
Evolve the existing Kludge system into a demo that we feel comfortable
showing to people outside Rand.
{
The demo is a vital part of our reporting requirements.
The demo is a vital part of our efforts to get continued support.
The existing demo is inadequate from many perspectives.
}
[July 1, Keith]
Expand our goal for the workbench to include it's use as a tool to
monitor and control the execution of parameterized (conditional)
plans. Develop additional motivation and determine any additional
features the Workbench might need to support such application.
{
Potential supporters of the research seem to have less trouble with
this type of use than with replanning.
Little in the way of additional system functions may be needed to support
this type of use.
}
[July 1, Barbara]
Develop a consensus about how the workbench ought to be used within
existing organizational planning situations OR how organizational
planning must be changed to accomodate use of the Workbench in order
to reap its benefits. Focus on how a big plan and rationale is going
to get entered into the system in the first place.
{
It is hard for most people to imagine how this technology will be
able to work in real organizations.
If we are going to work on a real planning task, we'd better be able to
specify in detail to the organization collaborating with us how we
are going to interact with them.
The design of any further retrieval capabilities for the demo software
depends on the assumptions we can make about how much structure will
be imposed on the database at the time it is entered.
}
[July 15, Keith]
Develop a consensus about the types of queries the Workbench will be
able to support. In particular, should it directly aid decisions at
high levels of abstraction (e.g., "if I now believe X and Y, which
parts of the plan can I still use") or should it only answer questions
about the relationships between the indivdual items in the database.
{
Our present direction is toward a system that requires the end-user
to understand the database structure so he/she can translate
questions about how to replan into lower level questions about
the relationships between plan structures and then figure out how
the answers to those low-level questions bear on his/her problem.
The system might be easier to use if it could answer the more
high-level questions directly.
}
INDIVIDUAL ACTIVITIES AND SUB-TASKS
[July 15, Norm, Keith]
Re-write existing Kludge software to use existing tools like
Lex and YACC.
{
Improve scope and efficiency of "conceptual" retrieval
Make software more easily extensible
}
[?date?]
Identify and implement features of a demo that will make it
attract the uninitiated and help convince them that a real
system will be worthwhile.
Things we can do now, without more hardware:
[Norm] character graphics (e.g., to draw/edit plan/rationale structures)
[Keith] menu-driven querying and maybe entry of database items and
structure
[Keith, Barbara] on-line interactive tutorial
[Barbara, Keith] off-line tutorial reference manual
{
The demo must be usable, if only to allow demonstrations where
users can themselves discover the value of such software.
}
[July 15, Bill, Barbara, Norm]
Elicit and record an entirely new bicycle plan and rationale under
more controlled conditions.
Act as if it was the first time we were working on a problem in
this domain.
Make it longer, more complex (e.g., a multi-day trip -- norm doesn't
really have to take it).
{
After developing a consensus about how the Workbench will be used
to elicit and record rationales we need to test those ideas.
The present rationale and plan have been compromised by ad hoc,
post hoc additions required to make our initial demo do any
interesting.
We need a plan that has more contingencies/alternatives in it if the
demo is to seem non-trivial.
}
[Aug 1, Bill, Rick, Barbara]
Select a real-world planning problem and have 2 or more of the the
project staff familiarize themselves with the domain to the extent
that they can serve as articulators for planners in that domain.
Generate an a priori conceptual hierarchy (e.g., a la LEX, for the
domain)
{
Demonstrate to a would be client that we are ready to move to a
real domain.
Get a feeling for how much conceptual structure for a plan and
rationale can be defined prior to planning and thus be available
to structure the database when a plan is being developed.
Be ready to start work in the domain as soon as we secure support
for the next FY
}
-------
---------------
-------
∂18 May 1981 2355-PDT RICK Plan revisions**2
To: Bill, Greiner, Wescourt, Barbara, Norm at RAND-AI, Mike
cc: rick
Folks:
I'm sending you part 1 from rand-ai.
Part 2 will come from the vax.
Rick
--------------
0<RICK.PLANNER>WORKBENCH-TODO-2..2 18-May-81 21:01:40, Edit by RICK
I really liked the plan revisions you generated. In fact, after many
hours, I haven't fully assimilated and balanced all of the suggestions.
I have some reservations however, owing to my desire to use the workbench
and to demonstrate some of the features I think are key.
Most of the proposed plan revisions were very "programmatic", i.e. they
helped specify what the people on the project should spend their time on.
These kinds of suggestions are on-target. However, I recognize now that
most of them are questionable, because we do not yet have a design in
hand for the demo system. A design would heavily constrain the programmatic
plans, more than is otherwise possible. My hope is that we can have that
design soon. I also think it can and should be more ambitious that kludge
is currently (not because kludge and its enhancements are unambitious, but
because we should be handling a richer set of replanning issues).
My primary objective is to complete this design. It should specify
what additional capabilities we believe are essential over what kludge now
provides, and it should also specify exactly how we are going to develop
these capabilities (what software, specifically, will be needed?). To do
that I think we should develop a hybrid programmatic plan that recognizes
an immediate need to "scope" the range of capabilities the demo system will
have. At the same time, we should specify our first cut at the specific
capabilities in each category. Then, in parallel, we should begin designing
the software and continuing along the research paths which support our work.
So, to do this, we need to flesh out the "demo" capabilities, in type
and minimum specifics. Then we need to design the software to go along with
those, and resume the research which is needed to pull off a good demo.
Below, I have added some "missing" goals (vis-a-vis the BHR&NS plan).
After that, I review the proposed plan revisions you generated (using
plusses and minusses to indicate my concurrence (disagreement) with the
proposed activities. After you have read this, prepare for a wednesday
discussion of the overall implied agenda. Thanks.
my goals which weren't satisfied by the proposed plan
g1. A system that I and others can use to manage project plans
g2. A system that helps enter, review & validate plan rationales
g3. A system that generates useful hardcopy (e.g., plan schedules)
g4. A system that accepts plug-in modules to support some domain
specific ramification (e.g., time and money calculations)
g5. A system that supports evolving plans and their rationales
g6. A system that accepts and exploits multiple levels of abstraction
g7. A system that answers specific (but generally interesting)
replanning questions.
g1. A system that I and others can use to manage project plans
pro> These are my biggest problems & the tool fits.
pro&con> this increases emphasis on immediately utility
infer> the system should support the exemplary plans we all
have generated, including BHR&NS's, BS's, RHR's,
& ROSIE
pro> this leads directly to probable FY82 application area
subgoal> g2 & g3 & g4 & g5 & g6
g2. A system that helps enter, review & validate plan rationales
pro> this is what the workbench is about
pro&con> emphasizes project breadth rather than depth
infer>this argues against deemphasizing rationale entry issues now
alternatives> for entering: integrate kludge with editor E
| build entry pgm
for review: integrate kludge with editor E
| build new review pgm
for validation: --what can we do here??
subgoal> specify ways for one item on entry to refer to others easily
g3. A system that generates useful hardcopy (e.g., plan schedules)
pro> very helpful & perhaps easier than general graphics
con> might be hard
example> BHR&NS's schedule at bottom of their workbench-todo revision
alternative> if plan rationales are in English & maintained by editor
they should be readable and printable simply
g4. A system that accepts plug-in modules to support some domain specific
ramification (e.g., time and money calculations)
pro> parameterized sentences & dependencies among them are important
con> this can be very hard
pro> project management has lots of good examples
pro> this is something that can be automated and can help replanning
pro> we should practice putting in hooks in ramification
alternative> create arithmetic equations between parameters &
respond to an edited sentence by ramifying the equation
pro> provides a possible source of "validation"
g5. A system that supports evolving plans and their rationales
pro> this is central to organizational replanning
pro> our plans for the project are evolving and hard to track
con> this can be hard
alternative> automate the recording of versions of items and
the linking of old and new items by an "update" pointer &
associate creator & creation time with items (this can be
done with special purpose calls from E or by a special pgm)
g6. A system that accepts and exploits multiple levels of abstraction.
pro> this helps organize the display of voluminous data
pro> this reflects the reality of many plans and rationales
con> this requires different "types" of items
con> the bicycle plan doesn't have it
pro> plans/rationales evolve often top-down (in organizations)
alternative> allow level names or numbers as part of item and
use appropriate pointer types for subordinates
g7. A system that answers specific (but generally interesting)
replanning questions.
example> Explain why one option was preferred to another
(e.g., x is more y than z)
example> What must be done BEFORE x?
example> Were there any alternatives to x that were rejected
for reasons concerning y?
∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT> Revisions to CORE project plan thru end of FY 81
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
GENERAL GOALS/CONSTRAINTS
[Rick]
Consolidate and package our efforts to date. If we find the project
is not to be continued, what can we present to the AF and the world as
our accomplishments.
{
We have a responsibility to the AF.
We want to be able to coherently describe what we've done to
colleagues.
We MAY need it to help secure further support.
}
--i assume we will continue beyond this year
[Rick]
Secure support for further work.
{
We want to continue the project.
++i assume we'll all play a role in this }
[Bill, Rick]
Associate the project with a real-world planning task either internal
or external to Rand, but external to our own immediate self-interests
(it can affect us, but should be someone elses problem and
responsibility).
{
++i personally like bill's idea to look into AF basing as a possibility
--i incline also toward project management (internal) for its benefits
Such a problem will motivate us to do better work.
Such a problem will give the project credibility and visibility that will
enhance its prospects for having a real outcome and our own
careers.
}
[Rick]
Maintain the productivity and happiness of project staff
{
+the best way i know how to do this is by a coordinated design cum programatic
plan
Promote the cohesiveness and stability of the project.
Increase the likelihood that the project will generate something
worthwhile.
Satisfy the personal goals of project staff
}
GROUP ACTIVITIES
[June 15, Rick]
Articulate a motivation for what we are doing that anticipates the
questions we have had directed at us in previous briefings and
discussions. Each staff member must learn that entire motivation.
+kw: please look at the WD and see what's missing if anything.
+ when we revise it, we'll take care of it
What is the problem?
Why do we think a primarily technological solution can solve
it?
Even if we can generate a solution, why do we think we can get
anyone to use it?
{
We need to be able to determine whether our efforts are making any
progress.
We should share a common perspective on what we are doing.
Everyone should be able to brief the project to clients/visitors.
}
[?date?, Norm]
Evolve the existing Kludge system into a demo that we feel comfortable
showing to people outside Rand.
-i think you need to be considerably more constructive here
{
The demo is a vital part of our reporting requirements.
The demo is a vital part of our efforts to get continued support.
The existing demo is inadequate from many perspectives.
}
[July 1, Keith]
Expand our goal for the workbench to include it's use as a tool to
monitor and control the execution of parameterized (conditional)
plans. Develop additional motivation and determine any additional
features the Workbench might need to support such application.
{--i think for now this is off the main-line
Potential supporters of the research seem to have less trouble with
this type of use than with replanning.
Little in the way of additional system functions may be needed to support
this type of use.
}
[July 1, Barbara]
Develop a consensus about how the workbench ought to be used within
existing organizational planning situations OR how organizational
planning must be changed to accomodate use of the Workbench in order
to reap its benefits. Focus on how a big plan and rationale is going
to get entered into the system in the first place.
--i think this is too hard now: let's focus on the demo
{
It is hard for most people to imagine how this technology will be
able to work in real organizations.
If we are going to work on a real planning task, we'd better be able to
specify in detail to the organization collaborating with us how we
are going to interact with them.
The design of any further retrieval capabilities for the demo software
depends on the assumptions we can make about how much structure will
be imposed on the database at the time it is entered.
}
[July 15, Keith]
Develop a consensus about the types of queries the Workbench will be
able to support. In particular, should it directly aid decisions at
high levels of abstraction (e.g., "if I now believe X and Y, which
parts of the plan can I still use") or should it only answer questions
about the relationships between the indivdual items in the database.
++ crucial, and right on
{
Our present direction is toward a system that requires the end-user
to understand the database structure so he/she can translate
questions about how to replan into lower level questions about
the relationships between plan structures and then figure out how
the answers to those low-level questions bear on his/her problem.
The system might be easier to use if it could answer the more
high-level questions directly.
}
INDIVIDUAL ACTIVITIES AND SUB-TASKS
[July 15, Norm, Keith]
Re-write existing Kludge software to use existing tools like
Lex and YACC.
- seems the cart before the horse: let's get the questions first
{
Improve scope and efficiency of "conceptual" retrieval
Make software more easily extensible
}
[?date?]
Identify and implement features of a demo that will make it
attract the uninitiated and help convince them that a real
system will be worthwhile.
-First, what is the point of the demo?
Things we can do now, without more hardware:
[Norm] character graphics (e.g., to draw/edit plan/rationale structures)
[Keith] menu-driven querying and maybe entry of database items and
structure
[Keith, Barbara] on-line interactive tutorial
[Barbara, Keith] off-line tutorial reference manual
{
The demo must be usable, if only to allow demonstrations where
users can themselves discover the value of such software.
}
[July 15, Bill, Barbara, Norm]
Elicit and record an entirely new bicycle plan and rationale under
more controlled conditions.
-i think the project management task is better
Act as if it was the first time we were working on a problem in
this domain.
Make it longer, more complex (e.g., a multi-day trip -- norm doesn't
really have to take it).
{
After developing a consensus about how the Workbench will be used
to elicit and record rationales we need to test those ideas.
The present rationale and plan have been compromised by ad hoc,
post hoc additions required to make our initial demo do any
interesting.
We need a plan that has more contingencies/alternatives in it if the
demo is to seem non-trivial.
-+ i'm not sure I follow this, elaborate please
}
[Aug 1, Bill, Rick, Barbara]
Select a real-world planning problem and have 2 or more of the the
project staff familiarize themselves with the domain to the extent
that they can serve as articulators for planners in that domain.
Generate an a priori conceptual hierarchy (e.g., a la LEX, for the
domain)
+ perhaps bill's current suggestion will pan out
{
Demonstrate to a would be client that we are ready to move to a
real domain.
Get a feeling for how much conceptual structure for a plan and
rationale can be defined prior to planning and thus be available
to structure the database when a plan is being developed.
Be ready to start work in the domain as soon as we secure support
for the next FY
}
-------
∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
0<WESCOURT.PLANNER>PROJECT-PLAN..5 8-May-81 13:17:32, Edit by WESCOURT
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
KW's Notation:
/kw == kw's rationale statements
{kw: ....} == kw's questions and suggested revisions
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
+ i found nearly all of your insertions throughout here illuminating.
you can see how much more is needed to "justify" this version of the plan
/kw searching for raw strings is inadequate
/kw conceptual structure must be accessible to encoder & retriever
> Easy conceptual extension
/kw encoder & retriever will develop new useful conceptual distinctions
as the workbench is used
/kw it is impractical for users to manually attach new conceptual
knowledge to existing items
> Good plan rationale entry, especially proof construction
/kw users cannot be trusted to enter consistent structures without
without aiding
> Some graphic display
/kw we believe that graphics are necessary to make stored rationales
understandable
> Some graphic editing
/kw given graphic display, graphic editing is a natural medium for
changing stored structures
> Reasonably complex problem
/kw outsiders won't be interested with successes on toy problems
/kw we want to work on something meaningful to us
/kw a complex problem is needed for us to discover the important
issues in building and using a workbench
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
/kw origin of plan contents and knowledge of plan evolution are
important for understanding and evaluating it-- they supply
additional, implicit rationale
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
/kw each person has some different skills and interests
/kw the rand environment stresses individual accountability
- i think that's wrong: i look for ways to divide & conquer
and to motivate individual excellence
/kw we think we will be more productive by subdividing responsibility
> Each specifies what he/she wants to produce
/kw this will make division of responsibility more meaningful
/kw we think we should be able to pursue our own interests within
the context of the project
> Collaboration to integrate designs
/kw given division of responsibility and individual choice of direction,
negotiation between individuals is essential to build a working
system
> A usable tool
> Viable, friendly, moderate speed and size
++ /kw the system must make a good impression on outsiders who use it
++ /kw we won't enjoy working with a slow, clumsy-to-use system
> A good self-contained demo & tutorial
/kw we don't want to be burdened with personally acquainting people
with the system
/kw people are impressed by systems that they can understand and learn
to use without hand-holding
/kw a system is not complete without documentation
> Complete our Kludge experiments by June 1
> Rerun the experiment
+ /kw we don't feel we learned enough from the first experiment
+ /kw the software wasn't adequate for the first experiment
? /kw we think we can do better the second time around
> Run the experiment on ourselves
+ /kw we all need to know how to use the software well
+ /kw we all need to be able to appreciate the system from the
users' point of view
+ /kw we all need to understand the cognitive/emotional aspects of
trying to do disciplined replanning.
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
+ /kw we are shooting for a Oct 1 demonstration
/kw we already have a set of objectives we know we cannot fully
satisfy by Oct 1
> Define a useful example
/kw we think that we cannot yet create a problem-independent
workbench so we need have the application clearly in mind as
we develop this prototype
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
/kw preprocessing will make retrieval faster at run-time
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
/kw we can't support arbitrary questions
--still need to:/kw we think we have identified the most useful/frequent types
of questions
> Allow a flexible language for describing patterns of both
conceptual and string matching
/kw the conceptual hierarchy will probably not be sufficient by
itself
/kw the user will be able to access the database and identify
raw strings useful for search
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches {kw: what does this mean?}
/kw we should support sysntactic as well as semantic variations
> Easy conceptual extension
{kw: this seems like it will be tricky with preprocessing}
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
{kw: How about using interactive menus driven by "planning grammars"}
- what benefits do you see? be specific on the type of entry.
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
/kw it is tedious to manually replicate the same structure for
several different plan steps
> Need implicit satisfaction of constraints by all actions
{kw: I'm not sure what this means}
+ subplans inherit constraints from about & presumably
satisfy them
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
+ /kw representation of some things by exclusion rather than inclusion
has certain advantages
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
/kw we think people generally want to limit or at least control the
level of detail they must see at any time
> Varying attributes/dates/designations of items => varying symbols
/kw people need powerful simple ways of distinguishing classes of
information
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
/kw emergency replanning is a very motivating problem for most people
at Rand
/kw we could all feel like we were contributing to society
++ yep, this would be a good one if we could find one & rationalize it
/kw emergency (re)planners need and WANT help now
/kw emergency planning organizations seem to lack some features
we feel may reduce the effectiveness of the workbench for
other organizations (e.g., the tendency to hide reasons from
others)
> A military one
/kw there is a lot of military expertise at rand
/kw the DoD is paying for this research right now
/kw the military needs planning help
/kw ~ it's hard to get access to military data for real,
interesting problems
/kw ~ most of us would rather not work on classified problems
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
++this sounds generally good to me
keith: plan evolution (retro & pro-active) & question-answering
{kw: tutorial, too. I see the order/priority of my tasks to
be question-answering; paln evolution; tutorial}
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
{kw: >> menus}
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
{kw: >> menus}
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
-------
∂15 May 1981 1331-PDT BILL revised plan with task assignments
To: rick
cc: barbara, norm at RAND-AI, wescourt
Bill's recommendation for overall plan, including his work assignments.
KEY ++ i found this to be pretty readable
g> goal
t> task
p> pro rationale
c> con rationale
s> status, comment
m> milestone
a> allocation, assignment
------------------------------------------------------------------------------
g> Lay groundwork for FY82 workbench research.
t> Report research results through FY81.
+ yes worth doing
m> Begin 31 Aug.
m> Complete 30 Sep.
p> Standard procedure.
c> Not in original plan.
p> Bill would like to help with this.
t> Analyze future workbench research alternatives.
- too late to help; always going on
m> Begin 31 Aug.
m> Complete 30 Sep.
p> Will help Rand and possible sponsors decide whether and in what
manner to support further workbench research.
c> Uses resources that would otherwise be available for demonstration.
c> Not in original plan.
p> Bill would like to help with this.
t> Generate and screen research alternatives.
t> Estimate impacts of research alternatives.
t> Evaluate research alternatives.
t> Demonstrate current capability.
--AI isn't necessary:
p> We want to demonstrate that AI techniques can help planners perform
some selected (re)planning function(s) better in some
specified respects than is presently done.
p> A necessary condition for further funding.
c> Not same wording as original goals.
--what do you think of bhr's existing demos?
m> Begin 18 May.
m> Complete 31 May.
t> Develop plan/rationale as vehicle for demonstration.
p> Necessary for any demonstration.
++this seems like a good task but I need to know more about it
p> Bill would like to work on this if the selected source were
a policy planning study, such as the Strategic Air Base study.
t> Develop plan/rationale entry capability.
++ i think this is very important
t> Identify application planning area for demonstration.
s> Possibly Strategic Air Base study viewed as plan.
p> Well known, classic Rand work; puts our research in
good company.
p> Basing is a current interest of Air Force.
p> R-266 presents relatively simple alternative unclassified
plans together with rich rationale.
+- replanning yes: but will the workbench help? how?
p> Demonstration should feature simple but highly
rationalized plan.
p> Examining R-266 as a source for base replanning has appeal;
analogous to Charles Wolf's recent examination of Hitch &
McKean's classic with respect to current situation.
p> Original participants still at Rand include Hoffman, Digby,
Hogg, Dadant, Augenstein, and DeHaven.
p> Forty page summary provides ample plan/rationale for our
demonstration; basic document of 380 pages provides greater
depth for specific points needing clarification.
p> Could be entered into database relatively fast.
- i don't see why you believe this
p> Bill would like to work on this.
t> Develop concepts for structuring rationale.
t> Conduct experiments to aid concept development.
- please be more specific
t> Develop plan/rationale processing software.
t> Design software.
s> Software should be usable by all of us.
s> Software should be usable by others under guidance of a
project member.
s> Software should support replanning in one or two selected
domains.
+++++ t> Specify (re)planning function(s) the demonstration
software will aid.
p> Functions identified in WD-963, slightly modified, include
++TOUCHE! DOCUMENT
Record
Update
COMPREHEND
Review
Brief
Interrogate
VALIDATE
Verify
Justify
ANALYZE
Detect
Assess
Compare
?? p> We can't do all the functions (review, brief, interrogate,
verify, justify, etc.) in the demonstration.
+Which? p> We should demonstrate feasible functions that most clearly
suggest the value of a computer aid to replanning.
p> Three clearly useful functions are better than more
less convincingly useful functions in demonstration.
t> Specify AI techniques to be embodied in demonstration software.
---- Only if very desirable
t> Determine hardware suite.
t> Determine mix of existing and new software to be utilized.
t> Determine mix of software for plan entry and modification.
s> Possibly unix, english parser, yacc, lex, or menus.
t> Determine mix of software for data base.
s> Possibly unix, berkeley's rdb system (isis).
t> Determine mix of software for conceptual encoding.
s> Possibly lisp, ellie/yacc.
t> Determine mix of software for query.
s> Possibly lisp, ellie/yacc, menus.
t> Determine mix of software for search.
s> Possibly rll, lisp, grep, isis.
t> Specify relationships between software and demonstration.
t> Code software.
t> Test software.
t> Develop display/graphics capability.
p> Graphics in itself has good selling power.
t> Determine mix of software for display.
s> Possibly small talk, megatek.
s> Possibly "flowcharting" software.
t> Determine mix of software for hardcopy generation.
r> We need hardcopy of session traces.
s> Possibly unix, laser, "flowcharting" software.
t> Develop meta-planning software.
m> Begin 1 Jun.
m> Complete 21 Aug.
p> There are possibly big benefits from meta-planning heuristics;
we should demonstrate some interest/capability in this area of AI.
s> Possibly Rosie software that would interact with planner,
suggesting to him or her how to use the mainline plan/rationale
processing software.
p> Rosie would facilitate fast development.
p> Rosie would provide friendly, transparent interface.
c> Would require using the 20.
p> Bill would like to work on this.
t> Design software.
-- this is possible, but you're statement of goals & tactic is vague;
also i feel this is cart before the horse, current task is the workbench
s> Possibly would use user description of current problem in
terms of menu-offered functions, modes, and roles to recommend
ways to use the mainline software.
--Huh? s> Possibly would have some capability to learn particular user's
replanning style and heuristics to suit that style.
t> Specify (re)planning function(s) the demonstration
software will aid.
p> Functions identified in WD-963, slightly modified, include
DOCUMENT
Record
Update
COMPREHEND
Review
Brief
Interrogate
VALIDATE
Verify
Justify
ANALYZE
Detect
Assess
Compare
--please tell me what you think replanning needs if you know.
t> Specify (re)planning mode(s) demonstration software will aid.
p> Planners faced with the same task differ in their mode of/
approach to (re)planning.
p> Mode specification helps structure (re)planning.
p> Observers of the demonstration will prefer different modes.
p> Modes imply heuristics, some of which we can model.
p> Some modal heuristics are too difficult to model in the
time available; hence we need to specify those we can do.
p> Software embodying modal hueristics could help (re)planners.
p> Bill would like to model modal heuristics.
p> Modes identified in Faludi's text on planning theory include
-- i don't see what you could do in this area? do you?
IMPOSING PATTERNS ON INFORMATION
Routinization
Sequential decisionmaking
Mixed scanning
CONTROLLED SUSPENSION OF RATIONAL PLANNING
Satisficing
A priori decisionmaking
Random decisionmaking
CREATIVE (RE)PLANNING
Convergent thinking
Divergent thinking
BALANCE
Open-mindedness
Will power
t> Code software.
t> Test software.
t> Develop demonstration tutorial.
p> Aids observers and effectiveness of demonstration.
p> Helps assure integrity of all parts of demonstration; as
disconnects will become apparent in tutorial development.
t> Specify system interfaces.
t> Specify the type of planners/planning software will demonstrate
being aided.
++ t> Specify the respects in which use of demonstration software will
be better than (re)planning without it.
t> Specify relationships between software and demonstration.
p> Whatever the software alone doesn't do to achieve the first
goal must be done by the demonstration.
t> Identify likely observers of demonstration.
>p Might be possible and desirable to tailor demonstration to
observers.
t> Stage the demonstration.
t> Design demonstration.
t> Prepare demonstration materials.
t> Make administrative arrangements for demonstration.
-------
∂TO Rick@Rand-Ai 15:38 20-May
Verbose Message
0) Overview of this message:
1) Meeting with Norm
2) Things I think I may understand, sorta
3) Major outstanding questions
4) Comments on SRI's SIPE paper
5) Ptr to Relations among rationale
6) Misc comments/problems (Rand-Unix)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
1) Whew - you didn't warn me about Norm's AntI-AI feelings.
Anyway, I learned a bit about UNIX, and attempted to describe
the basic idea of a frame based representation system.
I was then rather hazy about the nature and scope of my assignment;
and so could not have described it adequately to Norm.
That conversation did serve to expose
a wealth of possibly inaccurate perceptions of my role in
the task, which I hope your response (to part 3 in particular)
will help to clear up.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
2) As I understand my task, one part involves enumerating standard relations
which can be used to define new concepts.
I list below some obvious connective which relate pairs (n-tuples) of concepts
with one another. Note the arguments to these relations maybe
either "noun/adjective-like" (eg Naomi, Hilly) or "verb-like", as
in Like. I haven't resolved whether there should be seperate relations
for these cases.
(The vagueness you'll find in the descriptions mirrors my great uncertainty
about these connectors. I'll think harder about these, if you confirm that
I'm at least sorta on the right path.)
Synonym -
(Synonym x y) means x and y denote the same thing, in this context.
Hence, when scanning for y's, one should look as well for x's,
and vice versa.
Ex: (Synonym Wife Naomi) - in this example.
(Synonym Like Love) [taking liberties with English for this example]
Specialization -
(Specialization x y) means x denotes a specialization of y.
Hence, when scaning for x's, one should seriously consider any y's found;
as some y's will, in fact, be x's as well.
On the flip side, any x is AKO y, so use any x's found when trying
to find instances of y.
Ex: (Specialization GroceryStore Store)
(Specialization Like Affection)
[Yes, this may be slur of Element and Subset, and who knows what else.
For this application, though, I couldn't find any case where this
distinction ever made a difference.]
Generalization -
(Generalization x y) - this is handled as (Specialization y x).
Antonym -
(Antonym x y) means both x and y are the same "type" of thing,
but should be regarded as exclusive.
Hence finding x automatically means not y is not the case, and
vice versa.
Ex: (Antonym Flat Hilly)
(Antonym Like Hate)
Exclusive -
(Exclusive z x1 x2 ... xN) means all xi are specializations of z,
but are exclusive. This is clearly related to Antonym, but I'm
not quite sure.
Ex: (Exclusive Store GroceryStore HardwareStore)
(Exclusive BasicTastes Bitter Sweet Acid Sour)
-----
Note this isn't quite enough to handle those cases where
the arguments are "verb-like". Here we have to consider the order of
THEIR arguments, which may differ. Eg
(Synonym INTERESTs LIKEs)
would seem to imply
x LIKEs y <=> x INTERESTs y,
which is wrong.
The relation is really
Norm LIKEs roads <=> roads INTEREST Norm.
Perhaps we should use a slew of specializations of this Synonym relation,
to deal with various rearrangements of the arguments.
Another possibility, which I shy away from, is to define these interrelations
in predicate calculus -- eg
(All (x y) (EQUIVALENT (Match (x LIKEs y)) (Match (y INTERESTs x)))),
and shunk the above Synonym, Antonym, ... stuff above -- or rather, use it
only as a short hand, which expands into the form the inferencer "really"
uses, shown above.
This second possibility seems rather confusing to me; and may open a Pandora's
Box of further complications -- eg determining the sort of the variables
x and y above, or handling the modal operators which would eventually crop up.
Comments?
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
3) Now for things I really don't understand:
Just what do you want RLL to be able to do with such links.
Eg spse the systen knows (Antonym Likes Hates).
What sorts of inferences should RLL perform?
If the user now asks "What does Norm like?", what query should be fed to
Kludge (or its descendent)?
(i) For all rationales, r, of the form (Norm likes x), return
"Norm likes x" .
(ii) For all rationales, r, of the form (Norm hates x), return
"Norm does NOT like x" .
(iii) For all rationales, r, of the form (Norm <a> x) where
<a> is either Likes or Hates,
return each r for user inspection.
I had thought (i) and (ii) were expected for this task; Norm seemed to feel
(iii) is the desired answer.
Now imagine a harder challenge --
Design a trip involving more things which Norm likes to do.
Should RLL now know enough to propose an escape involving more of those x
such that (Norm likes x), and fewer y such that (Norm hates y)?
Again Norm shunked this is not-possible or even desirable; prefering
simply an enumeration like (iii) above; leaving the rest to the user.
---
This question could be resolved with a few I/O pairs --
First, what sort of inputs which you would like the user to be able to type
in, to link together appropriate concepts.
In that context, what sorts of questions should this RLL preprocessor expect
to see; and what DB queries should it generate (for Kludge) in response?
----
On a related theme, what other sorts of things should RLL know about?
(Especially assuming the front end is NOT predicate calculus,
[the suggestion I advised strongly against above],)
should it be able to handle quantifiers like SOME, ANY, ...
and quantifier-like things, eg MORE, LESS.
[This is necessary to deduce that "Less Boring" is a SYNONYM for
"More Exciting", given that (Antonym Boring Exciting).]
How about declaring that LongerThan is Transitive. This will allow RLL
to reason that Trip1 will be longer than Trip3, from the facts,
(LongerThan Trip1 Trip2) and (LongerThan Trip2 Trip3), stored in the data base.
For this task does RLL have to know enough to declare some new connection
invalid -- eg that it contradicts another declaration (in the sense
that (Synonym x y) and (Antonym x y) are incompatible), or that it violates
some type constraint -- should RLL be able to state that only animate things
can ENJOY some activity?
Feel free to answer any other question along these lines -- of what this
preprocessor should be able to do...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
4) I sent along the proto-IJCAI-candidate paper Dave Wilkins & Ann Robinson wrote.
Most of that project seems orthogonal to this project.
It is dealing primarily with interactive planning,
in the earlier Sacerdoti et al sense,
as opposed to providing easy means for subsequent replanning.
Its many built-in parts actually seemed rather similar to Wilensky's
current stuff; but that's neither here nor there.
The paper's most relevant part was its brief description of SIPE's
graphics interface, pp 12 - 14, ish.
Final note - feel free to read the paper, but NOT to quote it without permission.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
5) Understanding what sorts of links should join rationale and plan steps
with one other seems critical to my task.
Is Barbara "in charge" of this research area?
I concocted some relations which seem deserving; shall I send
them to Barbara for revision/demolition?..
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
6) What is the status of Rand-Unix? I've been totally unable to TELNET there.
(I always find myself REFUSEd.) Is there some trick?
Also, what is its site number? (IE To connect there from the local tip,
I type @L ?, for some number ?. Any idea what the number is?)
Anyway, is there someway I can find if I've any mail there; and if so,
get it forwarded to, say, GREINER@RAND-AI? Thanks.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Sorry about the ill-structuredness of the questions in this message;
and thanks, in advance, for your anticipated-to-be-illuminating response.
Russ
∂21-May-81 0802 RICK at RAND-AI reply to your msg
To: rdg at SU-AI
cc: rick at RAND-AI
Russ: My comments are at asterisks in your original. - Rick
---------------
Mail-From: SU-AI rcvd at 20-May-81 1539-PDT
Date: 20 May 1981 1538-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Verbose Message
To: rick at RAND-AI
0) Overview of this message:
1) Meeting with Norm
2) Things I think I may understand, sorta
3) Major outstanding questions
4) Comments on SRI's SIPE paper
5) Ptr to Relations among rationale
6) Misc comments/problems (Rand-Unix)
1) Whew - you didn't warn me about Norm's AntI-AI feelings.
**If i thought you needed protection, I'd have given it to you.
Anyway, I learned a bit about UNIX, and attempted to describe
the basic idea of a frame based representation system.
I was then rather hazy about the nature and scope of my assignment;
and so could not have described it adequately to Norm.
That conversation did serve to expose
a wealth of possibly inaccurate perceptions of my role in
the task, which I hope your response (to part 3 in particular)
**Your role is still ill-defined. Don't be alarmed by that.
will help to clear up.
2) As I understand my task, one part involves enumerating standard relations
which can be used to define new concepts.
I list below some obvious connective which relate pairs (n-tuples) of concepts
with one another. Note the arguments to these relations maybe
either "noun/adjective-like" (eg Naomi, Hilly) or "verb-like", as
in Like. I haven't resolved whether there should be seperate relations
for these cases.
(The vagueness you'll find in the descriptions mirrors my great uncertainty
about these connectors. I'll think harder about these, if you confirm that
**From what I see below, you're on the right path. That is supposed to be a
**path that leads to a capability to find stuff in the rationale which
**is related to other stuff (or just to words in English) by query-specified
** relationships. (Ie., can we do "knowledge retrieval" without completely
** general natural language understanding. I think yes. I suspect the
**capability required will combine three things: (1) a syntactically
**constraind syntax for english input; (2) a broad collection of domain-
**specific concepts (e.g., words, phrases); and (3) conceptual relationships
** like Synonymous(x does not verb y, x does (antonym verb) y)
**Thus, in what follows you are on the right track wrt (3), which is the area
**I asked you to focus on first. But you should comprehend (1-3) and tell
** me if i'm wrong in the overall approach.
I'm at least sorta on the right path.)
Synonym -
(Synonym x y) means x and y denote the same thing, in this context.
Hence, when scanning for y's, one should look as well for x's,
and vice versa.
Ex: (Synonym Wife Naomi) - in this example.
(Synonym Like Love) [taking liberties with English for this example]
Specialization -
(Specialization x y) means x denotes a specialization of y.
Hence, when scaning for x's, one should seriously consider any y's found;
as some y's will, in fact, be x's as well.
On the flip side, any x is AKO y, so use any x's found when trying
to find instances of y.
Ex: (Specialization GroceryStore Store)
(Specialization Like Affection)
[Yes, this may be slur of Element and Subset, and who knows what else.
For this application, though, I couldn't find any case where this
distinction ever made a difference.]
Generalization -
(Generalization x y) - this is handled as (Specialization y x).
Antonym -
(Antonym x y) means both x and y are the same "type" of thing,
but should be regarded as exclusive.
Hence finding x automatically means not y is not the case, and
vice versa.
Ex: (Antonym Flat Hilly)
(Antonym Like Hate)
Exclusive -
(Exclusive z x1 x2 ... xN) means all xi are specializations of z,
but are exclusive. This is clearly related to Antonym, but I'm
not quite sure.
Ex: (Exclusive Store GroceryStore HardwareStore)
(Exclusive BasicTastes Bitter Sweet Acid Sour)
-----
Note this isn't quite enough to handle those cases where
the arguments are "verb-like". Here we have to consider the order of
THEIR arguments, which may differ. Eg
(Synonym INTERESTs LIKEs)
would seem to imply
x LIKEs y <=> x INTERESTs y,
which is wrong.
The relation is really
Norm LIKEs roads <=> roads INTEREST Norm.
Perhaps we should use a slew of specializations of this Synonym relation,
to deal with various rearrangements of the arguments.
Another possibility, which I shy away from, is to define these interrelations
in predicate calculus -- eg
(All (x y) (EQUIVALENT (Match (x LIKEs y)) (Match (y INTERESTs x)))),
**This is just hwa the matcher needs. The best defining form might be a macro
**which combines this with the Synonym, etc. simpler forms.
and shunk the above Synonym, Antonym, ... stuff above -- or rather, use it
only as a short hand**Right: isn't it all just shorthand (ie,symbolic equivalents?)
, which expands into the form the inferencer "really"
uses, shown above.
This second possibility seems rather confusing to me; and may open a Pandora's
Box of further complications -- eg determining the sort of the variables
x and y above, or handling the modal operators which would eventually crop up.
Comments? (**Can't be avoided as far as I see. Push on!)
3) Now for things I really don't understand:
Just what do you want RLL to be able to do with such links.
**In general, I want RLL to convert a query into a regular expression for
**searching the data base: you tell me what patterns will match the query.
**Different query types will affeect how you translate a query into the
**eventual search pattern. Ultimately, not now, I want the system to
**grow into an intelligent formulator of patterns for retrieval search, one
** that will suggest its "best" ideas first, and then follow-up with alternat-
**ives if the first doesn't pan out.
Eg spse the systen knows (Antonym Likes Hates).
What sorts of inferences should RLL perform?
If the user now asks "What does Norm like?", what query should be fed to
Kludge (or its descendent)?
(i) For all rationales, r, of the form (Norm likes x), return
"Norm likes x" .
(ii) For all rationales, r, of the form (Norm hates x), return
"Norm does NOT like x" .
(iii) For all rationales, r, of the form (Norm <a> x) where
<a> is either Likes or Hates,
return each r for user inspection.
I had thought (i) and (ii) were expected for this task; Norm seemed to feel
(iii) is the desired answer.**Obviously, you're both right. It depends of
what type of Q it is. One "type" corresponds to each of the possible answers.
**E.g., (1) Scan the rationale for "Norm likes x".
(2) Scan the rationale for ~"Norm likes x"
(3) Scan the rationale for items about "Norm likes x"
Now imagine a harder challenge --
Design a trip involving more things which Norm likes to do.
Should RLL now know enough to propose an escape involving more of those x
such that (Norm likes x), and fewer y such that (Norm hates y)?
**Not by itself (at first). But if I want to say that that's the meaning of
** the concept ("Better for norm"), I'd like to be able to extend the concept
** base in an easy way so the answer to "What's better for norm?" will find
** just the right things and prhaps help me understand whichitems matched
**which part of the branched conceptual definition.
Again Norm shunked this is not-possible or even desirable; prefering
simply an enumeration like (iii) above; leaving the rest to the user.
**Norm doesn't want to try to solve problems he doesn't know how to. You
**do, and so do I. So you need higher aspirations. But don't expect
**Norm (or anyone else) to think you wll succeed. Even I think you might
**fail because it's hard: you must specify a currently unslved problem
**well, and then solve it well.
---
This question could be resolved with a few I/O pairs --
First, what sort of inputs which you would like the user to be able to type
in, to link together appropriate concepts.
**We are about to generate lots of "replanning specific questions" which should
help give you illustrations. Make up your own, e.g.,
Replan to make the trip shorter=>need to find those things that determine
trip length & alternatives to them which might inversely affect length ->
Query: Items about TripDuration -> Items about TripPartLengths & Items about
TripPartSpeeds & AlternativesToTripParts(x) & LengthsOf(x) & SpeedsOn(x) ->
"Kludge: find all the items where "x is a part of the trip" or "the trip
includes x", feed each x back to me" & (for all x received) "Kludge:
final all the items whre "y is the length of x" or "x is y DistanceUnits""...
**Note, BIG QUESTION: Obviously, I'd like to have the ability to just say
to my DB, "Find all items(x,y) such that x is a trippart and y is the length
of x". But I don't know how to do that in one system we can build today,
given the relatively free and breezy form of plan items. So, I'm trying to
find a hybrid of "logical inference" in RLL and fast string matching in Unix.
Do you think the whole system could be done in RLL, even with the long
and verbose string matching? (Realizing that we expect 10**4 or more items?)
It doesn't seem likely. So we need to continue conceptualizing how some of
the smarts about what to look for, in what order, can be done in RLL. As my
preceding example suggests, it might be a dialog of sequential interactions
between RLL And KLUDGE just to answer prt of a complex question. The
advantage to doing this in RLL should be that we could modify both the
concept definitions and the interactive dialog definitin required to answer
complex queries. I don't know exactly waht it will take at this time.
**end
In that context, what sorts of questions should this RLL preprocessor expect
to see; and what DB queries should it generate (for Kludge) in response?
----
On a related theme, what other sorts of things should RLL know about?
(Especially assuming the front end is NOT predicate calculus,
[the suggestion I advised strongly against above],)
should it be able to handle quantifiers like SOME, ANY, ...
and quantifier-like things, eg MORE, LESS.**YES**
[This is necessary to deduce that "Less Boring" is a SYNONYM for
"More Exciting", given that (Antonym Boring Exciting).]
How about declaring that LongerThan is Transitive. This will allow RLL
to reason that Trip1 will be longer than Trip3, from the facts,
(LongerThan Trip1 Trip2) and (LongerThan Trip2 Trip3), stored in the data base.
For this task does RLL have to know enough to declare some new connection
invalid -- eg that it contradicts another declaration (in the sense
that (Synonym x y) and (Antonym x y) are incompatible), or that it violates
some type constraint -- should RLL be able to state that only animate things
can ENJOY some activity?**Nice, but not essential.
Feel free to answer any other question along these lines -- of what this
preprocessor should be able to do...
** Iwant to convey to you a sense of what the problem is in designing a
"real intelligent system". The basic idea is that all intelligent systems
have high-payoff, high-technology mechanisms of limited genral utility and
also a lrge number of low-payoff, low-technology mechanisms of more general
utility. Humans are a great example: we often resort to slow, tedious
manual and even exhaustive methods to solve problems for which we can't
simply solve by our high-tech methods. Our planners workbench will
necessarily be much like this. Your use of the word "preprocessor" is both
accurate and misleading. I want you to build in RLL a highly-intelligent
system that helps us find useful information in the ratinale database.
This mechanism that you build must be domain independent and easily extended
in a mature domain application. It has to guide us in choosing how we
apply our expensive, low-tech methods, such as string searching and
following inter-item pointers through a large file system. Those are the
slow parts (inherently so). By comparison, a little thinking by RLL might
be worth a lot. Can you show me how?
4) I sent along the proto-IJCAI-candidate paper Dave Wilkins & Ann Robinson wrote.
Most of that project seems orthogonal to this project.
It is dealing primarily with interactive planning,
in the earlier Sacerdoti et al sense,
as opposed to providing easy means for subsequent replanning.
Its many built-in parts actually seemed rather similar to Wilensky's
current stuff; but that's neither here nor there.
The paper's most relevant part was its brief description of SIPE's
graphics interface, pp 12 - 14, ish.
Final note - feel free to read the paper, but NOT to quote it without permission.
**ok, thanks
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
5) Understanding what sorts of links should join rationale and plan steps
with one other seems critical to my task.
Is Barbara "in charge" of this research area?
**Yes, she's currently in charge, but that means you should interact withher,
not assume she has it all worked out and will dictate the truth.
I concocted some relations which seem deserving; shall I send
them to Barbara for revision/demolition?..
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
6) What is the status of Rand-Unix? I've been totally unable to TELNET there.
(I always find myself REFUSEd.) Is there some trick?
Also, what is its site number? (IE To connect there from the local tip,
I type @L ?, for some number ?. Any idea what the number is?)
Anyway, is there someway I can find if I've any mail there; and if so,
get it forwarded to, say, GREINER@RAND-AI? Thanks.
**I have no idea why you're having trouble. Please call Keith or Doris
McClure to find out what's the problem.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Sorry about the ill-structuredness of the questions in this message;
**No apology necessary. You're grappling with a tough, mushy problem.
and thanks, in advance, for your anticipated-to-be-illuminating response.
Russ
---------------
-------
∂To BARBARA@Rand-Ai 17:08 21-May
Relns connecting Rationale & PlanSteps
At the meeting last week I objected that there were a host of
distinct relations which may connect a rationale with its "underlings",
and promised to attempt to enumerate a few of them.
I soon realized there are four categories of relations,
depending on the "domain" and the "range" of the link --
as either may be either a step of a plan or a rationale.
For notation I will assume the link, of type LinkType, connects
from HEAD to UNDERLING.
Note: I never was clear in what way a plan step
is different from a rationale. Indeed, Norm gave me the impression they
were indistinquishable, at least to his programs. In the descriptions which
follow I am assuming a plan step actually corresponds to some doable action(s)
which might take place in the "real" world; whereas a rationale is a non-temporal
fact which is assumed true in the world.
(I used scare quotes above in case we later consider meta-plan, in which case
this real world would include our thoughts as well...)
[Or do you hold the view that each Plan step be considered more like Goal?]
You'll no doubt notice a frame-like notation creeping into the examples below --
looks like I am a victim of my breeding after all. I did try to think of some
other form, but none seemed as natural and obvious...
*-*-*-*-*-*-*
PlanStep - PlanStep
[In many cases, especially those denoted with a leading "*",
there might really be some rationale implicit in
these links, which indicate why the plan steps are so joined.
In such cases, just assume these connections are simply shorthand
notations for that more elaborate connectin...]
SubPlans: To achieve the large plan HEAD one must perform, (in any order,)
each of the SubPlans, UNDERLING.
[Note there is an implicit CONJUNCTION around the members of SubPlans.]
Example -
CleanUp-Room
SubPlans: ({Make Bed}, {PickUp Clothes} ...)
SuperPlan: This is the inverse of SubPlans.
SpecializePlan: The UNDERLING is a refinement of HEAD. Example -
Norm goes to a Store.
SpecializePlan: Norm goes to a Grocery Store.
SpecializePlan: Norm goes to Draegers.
-- Note SubPlans is NOT the same as SpecializePlan.
It is true, however, that one can view any SpecializePlan as
a SubPlan; but not vice versa.
GeneralizePlan: This is the inverse of SpecializePlan.
NotSubPlan: This connects a planstep to each other planstep which are
not its subplans. It would be explicitly (ie physically) indicated
only where there might be some question as to UNDERLING's connection
with HEAD.
* DoBefore: Lists the subplans which should be done before HEAD.
Example -
Paint the ladder.
DoBefore: ( {Paint the ceiling}, {Paint the chandalier} >
* DoAfter: Inverse of DoBefore.
OrderedSubPlans: Perform each of the UNDERLINGs in order.
[This is a short-hand for the appropriate SubPlans link, and a DoBefore
connecting each member of that list with its respective
succeeding member.]
* Incompatible: HEAD and UNDERLING cannot both be performed. (Possible neither
will be executed.) (Note Incompatible is its own inverse.) Example -
Bike to work.
Incompatible: Drive (a car) to work.
* CoOccuring: Whenever HEAD happens, UNDERLING must be performed as well.
(Note CoOccuring is NOT its own inverse.) Example -
Shoot arrow into air.
CoOccuring: Arrow falls to ground.
[This is a bad example, as they are connected by a stronger causality
connection... See below.]
* Causes: HEAD caused UNDERLING to happen. Example -
Turn on water.
Causes: Water to flow out of spigot.
* Effect: Inverse of Causes.
-- The next set of links are special cases of SubPlans -- they each point
from some action, HEAD, to one or more actions which, if performed
in some way, would achieve HEAD. Many use "runtime" information.
That is, at "compiletime", when this plan was generated,
some information necessary to make a critical decision was missing.
ConditionalSubPlan: Perform the subplan, UNDERLING, iff the associated test
returns true. Example -
Norm goes outside.
ConditionalSubPlan: < {if raining} {Bring an umbrella} >
[test /\] [plan step /\]
-- Note this could be expanded to be like an If-Then, or even a general LISPy
COND. (Other bells-and-whistles include SELECTQ-like subplans, ...)
RepeatUntil: This is iteration, where the termination will be determined
based on some "runtime" test.
See all possible sites.
RepeatUntil: < {out of time?}, {See a site} >
[test /\] [Plan step/\]
[I feel really funny about this connection -- still it does seem
natural. Perhaps it should be created by using the ConditinalSubPlan
and a more primitive LOOP subplan. Who knows?]
*-*-*-*-*-*-*
PlanStep-Rationale
RationalePro: Gives reasons for this planstep. Example -
Go home at 9PM on Mondays.
RationalePro: I want to be home at 9PM on Mondays.
RationaleCon: Gives reasons agains this planstep. Example -
Go home at 9PM on Mondays.
RationaleCon: I cannot do computer work at home.
-- The next link points from a step in a plan to a <something>.
Having adopted the view that anything which is not a planstep
is a rationale, it is included in this PlanStep->Rationale category.
Comments: This points from a plan step to a statement which may, somehow,
be later seen to be relevant.
It may be a question -
Go home at 9PM on Mondays.
Comments: What if I've a lot of extra work to do?
or a meta statement -
Go home at 9PM on Mondays.
Comments: If I'm not sure whether to follow this or not,
then don't.
or just random (at least in appearance) -
Go home at 9PM on Mondays.
Comments: If Silverman goes from CBS to NBC, reconsider this command.
[yes, yes, yes -- there really was a long chain of derivation
which might have lead to this, but ...]
*-*-*-*-*-*-*
Rationale-Rationale
Supports: Gives reasons for this rationale. (Note this is like
RationalePro.) Example -
I want to be home at 9PM on Mondays.
Supports: < {I can watch TV at home (and not from work).}
{M*A*S*H is on TV at 9PM Mondays.} >
Opposes: Gives reasons against this rationale. Example -
I can do computer work at home.
Opposes: < {I have no terminal at home.} and
{I need a terminal to do computer work.} >
Specialization: Like SpecializePlan. Example -
I want to be home in the evening.
Specialization: I want to be home at 9PM.
Generalization: Inverse of Specialize.
*-*-*-*-*-*-*
Rationale-PlanStep
RatProOf: [Inverse of RationalePro]
RatConOf: [Inverse of RationaleCon]
*****
The above list is by no means complete; but do somewhat correspond to
my intuitions on what sorts of things people will want to say.
I'd be interested in comments -- especially if it turns out I'm
totally wrong about some assumption which led to these.
Still to do
I would feel a sense of closure if I felt we had a sufficient class of
connective to "map" all of the connectives
found in predicate calculus - AND OR NOT EVERY EXISTS.
Some of these are already handled --
eg AND was handled by the SubPlan, in all of its flavors.
NotSubPlan is like NOT, and ConditionalSubPlan can be used to
awkwardly simulate OR.
The others (eg quantifiers) may or may not even be relevant...
Thoughts?
[EG "Norm needs a place to stay" does have an existential. Should
it be represented as such?]
As shown above, there are clearly at least two main decision times
which must be considered -- plan generation, and during plan execution.
[Are there others?]
In later case, should the information be preserved in some rationale,
or in the actual plan steps? I chose the latter, as the most canonical
location. (or should there be IF-THEN clauses in a rationale which decides?)
Have you devised a formalism for encoding meta-level statements --
eg about when to decide what to do, or how much (?many?) resources to expend
in deciding? Or, more generally, about what inference procedures to follow?
*****
My hope is that eventually this Planning System has a wide range of these
links; which are each well-understood -- each relation corresponding to
a predicate calculus formula. The user, I envision, will be able to add
on his own connectives, provided they are as well defined.
---
Thanks for your comments -
Russ
∂25-May-81 1407 barbara at RAND-UNIX Re: Relns connecting Rationale & PlanSteps
In-reply-to: Your message of 21 May 1981 1708-PDT.
From: barbara at RAND-UNIX
Hi Russ -
I have taken the liberty of forwarding your message to the
other members of the project, so you may be hearing from them as well.
I have a few reactions to your proposals:
1. I think you did a nice job systematically enumerating many important
kinds of relationships between a HEAD and its UNDERLINGS. The bike trip
protocol (i.e., the transcript of the discussions in which we generated the
plan) contains instances of almost all of the relationships you mentioned
(although, of course, they are not all coded explicitly
in the current rationale).
2. I believe there are other potentially useful types of relationships.
Example: Structured arguments.
The protocol contains some instances of well-structured
arguments of the form: Premise A, Premise B, ..., Therefore Conclusion.
In other cases, a statement in the protocol is supported by a list
of more or less independent reasons. Some statements benefit from both
types of support and there are probably others as well.
In any case, we might want to explicate the nature of the argument
underlying a particular statement and the exact
relationships among its constituents.
Example: Domain-specific functional relationships
Resource requirements are a major consideration in the bike trip plan.
It might be useful to code them explicitly so that we could easily
answer questions like--How much money does Norm need and which parts of
the plan require cash?
3. As I understand your approach to this problem, you are trying to
enumerate a "complete" set of relationships, capable of capturing
everything planners might express during a planning episode.
Another approach would be to enumerate those relationships that
would provide useful functions during plan review, plan evaluation,
plan modification, etc. What functions will the relationships you proposed
provide? What questions will they answer?
How will they help somone understand or use the rationale?
4. Most of your assumptions (e.g., about plan versus rationale)
were correct. Your terminology is different from the Rand group's
terminology, but easy to understand.
5. Another useful "time" (in addition to plan generation and plan execution)
is plan modification time. How do we keep track of successive states
of an evolving plan and their relationships to one another?
6. General issues of timing planned actions are apt to be more complex than
"before," "after," and "until." Consider: at 5:00, during the ascent,
within 60 seconds of landing, for at least two hours.
That's all for now. I hope these comments are useful.
Barbara
∂To: (%Rand-Ai Bill, Rick, Wescourt, Barbara, Norm, Mike) 17:24 29-May
Comments on Keith's Proposal
I read this message with an eye towards encoded the necessary data
in RLL. As my comments below may show, there does seem to be a
fairly good fit. (In many cases this is simply a property of any
object-centered data base; other features come for free on any system
built on InterLisp (IL); only a few seemed to require a less
"trivial" feature of RLL.)
[My comments are prefaced by *-*-*.]
--------
∂27 May 1981 1136-PDT Keith Wescourt <WESCOURT> Proposed features for demo system
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
Here is a relatively unordered list of features to be considered
for the design of our demo system. "Rationale" for each proposed
item follows in an indented block surrounded by curly braces. I
have not yet added rationale for all the proposed features.
The system should combine plan rationale entry and question-answering
(retrieval) functions.
*-*-* RLL would provide each item with a name, which would permit the
*-*-* needed handle to re-access it. It is trivial to read (or even
*-*-* modify) one unit while still creating/editing another.
{
The user may have to refer to existing items when entering or
modifying a particular item.
The user may notice errors or deficiencies in database content
or structure during retrieval and wish to modify the database at
that time.
}
The command scanner should be specific to the system's command set.
{
Erroneous user inputs should not cause random things to occur
(e.g., delete all his/her files, invoke some other program, etc).
*-*-* First, as RLL is in IL, there is little the user could do
*-*-* (in ignorance) which would affect the outside environment
*-*-* (that is, anything outside IL).
*-*-* Also, many of the RLL's major destructive functions
*-*-* (such as DeleteUnit) are undoable.
The command scanner should support both concise and verbose input.
{
Variations of expertise with the system, both between and
within users, require a range of input detail for user comfort.
}
*-*-* RLL currently has no convenient input facility. Such an
*-*-* interface would have to be constructed, eventually.
The command scanner should provide interactive prompting (a la the
TOPS20 EXEC) including noise words, completion/recognition of input,
and explanation or enumeration of legal inputs in response to a
'help character'.
{
Users should not have to interrupt what they are doing to obtain
simple sorts of help.
*-*-* I know of hooks into IL which provide this. RLL has yet to use
*-*-* any of these.
Since the system may change rapidly, integrated on-line help may
be easier to maintain than off-line help.
*-*-* Each of the functions would be encoded as a unit. This documentation
*-*-* could be stored there, perhaps at various levels of verbosity.
*-*-* (Some thought would have to be given to the more general problem
*-*-* of deciding how to administer more general aide, of course.)
Completion/recognition helps teach users about acceptable concise
inputs.
*-*-* Once again IL has a host of such I/O functions which we can tap.
Enumeration of finite options is useful when the option set may
be routinely modified by normal user interactions.
*-*-* The unit associated with such functions can store these options,
*-*-* and perhaps make trivial, "optimizing" changes to the function's
*-*-* definition as these options are dynamically changed.
*-*-* (One such alteration would be to permit that function to provide
*-*-* completion/recognition of allowable options, when queried...)
}
Each 'item' in the database will be an object and associated
attributes, including in addition to it's content:
*-*-* Any of these could be implemented in any object-centered language.
*-*-* RLL would provide a ready mechanism for defining these slots --
*-*-* For example, one might say each such slot, S, has the property
*-*-* that each time a new value is stored on U:S (the S slot of the
*-*-* U unit), the value of U:TimeOfLastAlteration would be updated.
*-*-* A more complicated version might involve storing, say,
*-*-* the current context, or IN list of assumptions.
*-*-* These could be retrieved and examined later.
*-*-* (An economizing move might involve storing this sorta stuff in
*-*-* some global variables whenever a value is retrieved...)
an edit history-- a list of pointers to previous versions of the item.
{
Users might want to revert the database to an earlier form.
Users might want to examine how a specific item has evolved and
explore why.
}
the date of last modification
{
Users might want to know how up-to-date and item is.
Users might want to use this date as a qualifier for retrieval
}
the name of the last writer
{
Users might want to contact this person with questions not answerable
from the database itself.
Users might want to use the source of an item as a qualifier
for retrieval.
}
the reason for the last modification
{
This is rationale for the item's modification.
This information can be represented more compactly as an item
attribute than as a separate item in the database (e.g., it
is permanent and non-editable.
*-*-* Oh, so you think history can't be changed. We'd better finish this
*-*-* project before 1984...
*-*-* Seriously, this leads to an important point: RLL lets the user
*-*-* decide which of these attributes should be stored, and in what
*-*-* format. (For example, the time stamp alone might be sufficient
*-*-* to determine everything else you need -- IF accurate records
*-*-* were kept indicates who was editing this data base when, and
*-*-* the sorts of things he was then focussing on, and what his rationales
*-*-* were, ... This would involve storing the "dual" of the data base
*-*-* outlined above; and this IS possible to do in RLL.)
*-*-* Even these decisions could later be altered
*-*-* -- RLL will have the capability of
*-*-* converting from one format to the other, "invisibly". That is,
*-*-* the user would call upon the same access/unpdating functions,
*-*-* which would retrieve the
*-*-* same values. The difference would be that these functions would
*-*-* have been rewritten to look at different places.
*-*-* (To skeptics who challenge this claim: Much of this can be achieved
*-*-* using known canned algorithms.... [Each of the components would
*-*-* have sufficient self-knowledge to "know" which of these procedures
*-*-* is appropriate.] More complex versions involve constructing these
*-*-* procedures from sub-chunks -- like gluing together subprocedures into
*-*-* a working whole. The final leap would be automatic programming-isk --
*-*-* generating these programs from "first principles".
*-*-* I'll worry seriously about this only when those canned procedures
*-*-* prove insufficient...)
}
a list (possibly null) of keywords explicitly assigned to the item
{
Users can categorize items a priori in ways that would be
difficult, expensive, or impossible to do with pattern matching
on those items' content.
*-*-* Ok - this is sorta what I was doing. Perhaps this could be done
*-*-* pseudo-automatically:
*-*-* If the user stores that list of keywords, these would be used for
*-*-* any and all matching which occurs. On the other hand, the trusting
*-*-* use may omit this list, and allow RLL to fill it in. Various cute
*-*-* syntactic tricks could be used to extract the relevant-seeming
*-*-* phrases from the otherwise unused English text, and these would
*-*-* then be stored as that item's keywords, and used for those matching
*-*-* steps. (Alternatively the user would be asked if those words are
*-*-* appropriate, and allowed, then, to alter them as he sees fit.)
*-*-* [EG the routine the NS (news service) program uses is quite nice.]
*-*-* Anyway, the user would always be permitted to modify this list
*-*-* if he thinks it inaccurate, or simply inefficient.
*-*-* **** A first crack at this can be found in the file <CORE>UNITTED.ITEMS,
*-*-* which includes with each item a list of sloppily determined keywords.
*-*-* (The code which generated keywords from english text took all of half
*-*-* a day to write, and the results seem reasonable if not perfect.
*-*-* (The interested user is refered to <GREINER>MU..) I'm confident better
*-*-* results would come from more work along these lines.
}
a list (possibly null) of labeled pointers to other items
{
This a uniform method for representing a labeled, directed graph
structure.
We believe the structure of plan rationales can be represented
by labeled, directed graphs.
*-*-* Here, here! We should decide which links should be included for
*-*-* the initial system. (My message to Barbara contained a collection
*-*-* of first thoughts on this...)
*-*-* As it evolves, new links could readily be added.
*-*-* (This ability is inherent in object-centered frame-like systems;
*-*-* but it is RLL which makes this task easy.)
}
the 'owner' of the item
{
The database should provide accountability and explicit
responsibility for access control.
}
a list (possibly null) of legal writers of the item in addition to
the owner
{
The owner may wish to allow certain other users to change an item.
*-*-* Easy to achieve in RLL -- by using a PutValue function which checks
*-*-* the LegalWriters slots of U before permitting U:S to be changed.
*-*-* (Note many of these restriction would apply only to top level
*-*-* modifications; that is, those which the user does by hand.
*-*-* RLL's "truth maintenance" would still be
*-*-* permitted to do things like updating back pointers.)
*-*-* This LegalWriters slot should be defined to prevent its value from
*-*-* being changed by anyone. It could easily be designed to allow all members
*-*-* of a class of units to (cheaply) "inherit" the same group of writers.
}
a list (possibly null) of legal readers of the contents of an
item in addition to the owner
{
Access to certain information may have to be restricted
*-*-* Same process mentioned above, for GetValue.
}
[note: write/read access might be controlled via centrally defined
groups instead of lists stored with each item]
The system should interface with a message sending system to allow
easy notification of an item's readers/writers whenever the item is
modified.
*-*-* IL does allow this, but it might be tricky. Better would be
*-*-* to have a RussGreiner unit in the system, which "receives" all
*-*-* of these messages, and reports them to me when I enter this system.
{
Users should be able make certain others know about specific
changes.
Users should be able insure that they are notified when
specific items or classes of items have been changed
An explicit interface to a message system will provide for
more uniform and thus more easy to process notifications
(as opposed to arbitrary inter-user messages)
*-*-* Why? I assume by "message system" you mean the one the system
*-*-* provides (ala MM). I'd rather see all of my Pencil messages
*-*-* when I'm in a position to do something about them -- ie when I'm
*-*-* in its environment.
*-*-* Note also that there are other advantages to explicitly storing
*-*-* facts about the user him(her)self: RLL can hang a host of other
*-*-* specific facts about that person here -- such as "common typing
*-*-* error", to help when previously unknown words appear in the
*-*-* English text s/he typed, or when non-existant functions are invoked.
*-*-* "Level of expertise" could be stored, and used when printing out
*-*-* comments and error messages. (The list goes on...)
}
The system should maintain a local edit history for items modified
during a session. The permanent edit histories are updated from the
local histories only at the end of session or when the eser explicitly
gives a command to do so during a session.
*-*-* As before, RLL provides handles for this. The naive approach,
*-*-* of tagging each unit with the meta-information about its recent
*-*-* alterations, will consume a bit of space. There are more sophisticated
*-*-* ideas (eg writing each update on an external file) which may
*-*-* correspond to a different point on the time-space tradeoff.
*-*-* Which to use, of course, depends of this depends on the
*-*-* use of this data.
{
Any changes to the database should require an explicit
confirmation before they are available to other users.
Users should be able to introduce hypothetical information
and explore its consequences without affecting other users.
*-*-* Perhaps a Hendrix/Fikes-ian "Partitioned Semantic Network"
*-*-* would work here. RLL doesn't yet know about this, but
*-*-* would be easy to teach.
An item's permanent edit history should not be cluttered with
changes due to errors.
}
The system should support manipulation of items via their edit
history-- i.e., reverting specific items or classes of items to
prior states, where class should be taken to mean any set of
items that can be selected via their attribute values. For example,
"revert all items with keyword USSR, written by Jones after 1-Mar-81
to their state on 1-Mar-81".
*-*-* Do realize that this is really meta-information -- ie not about
*-*-* the planning task per se, but rather about how and when the
*-*-* the plan was constructed. While I agree it should handled and
*-*-* used, the basic mechanisms may need to be different
*-*-* from the tools used for manipulating data in the base domain.
*-*-* (This is NOT the case now in RLL -- one uses the same access
*-*-* functions for any facts, regardless of (meta-)level.)
There should be three modes for entering/modifying items
1) unrestricted via a full screen editor
2) selective via a passive, attribute-at-a-time command scanner
3) selective via an dynamic, attribute-at-a-time menu system
*-*-* Mike Genesereth and I worked out a list of parameters which
*-*-* serve to characterize an editor. The above list does not
*-*-* mention, for example, when the data base updates (eg creating
*-*-* backpointers, or invalidating dependent values) are performed.
*-*-* (If you think it relevent I'll search for that list, and forward
*-*-* it along.)
The validity of entries and changes should be checked at the time
they are entered.
*-*-* Why? Perhaps some fallacious value for a slot should be allowed
*-*-* temporarily --
*-*-* for example, you may wish to characterize some intensional
*-*-* object for a while before "anchoring" it. Or you may want
*-*-* to store a value V in U:S before actually defining V.
*-*-* (I'm not advocating that approach, just commenting that I don't
*-*-* find your assumption obvious.)
This includes the legality of attributes and
their values (possible for some types of values like dates, keywords).
This checking is virtually automatic for the selective input modes,
because the menu system is driven by the syntax and semantics of
the legal grammar and the command scanner can apply the same grammar
either a character-at-a-time or a word-at-a-time to typed input.
For unrestricted input, a parser would have to process the text
returned from the editor.
Items should be retrievable by specifying any combination of attributes
and values. Any value for any attribute (not just the 'content' of the
item) can be represented in some sort of general expression grammar.
*-*-* RLL does not yet have any such matcher. Given its basis on CORLL
*-*-* (which permits most units to be stored on external disk most of
*-*-* the time) this process might prove quite expensive (requiring
*-*-* a slew of things to be swapped in and checked.) Of course this
*-*-* depends critically on how the data is stored, and which
*-*-* combination of "fields" serve as keys. [I question whether you
*-*-* really mean ANY value of ANY attribute.]
*-*-* (EG if the key is only one
*-*-* field, this retrieval could be driven by a backpointer from the
*-*-* unit which represents that key value.)
*-*-* Anyway, as this may be a crucial factor in deciding on the
*-*-* representation to use, we should discuss this at length.
Retrieval via the pointers attribute should be a special mode supported
by graphics i/o. That is, the user should be able to "move" around in
the network graphically displayed to show the connections (relationships)
between items. Three movement modes should be available: commands from
the keyboard that allow arbitrary movement; local moves via commands
(e.g., arrow keys) from a keypad; analog control from a joystick/trackball
type device. Graphic display should be zoomable to display different
levels of detail.
*-*-* I've put no graphics facilities into RLL. Doug, however, has spent
*-*-* a while fixing such a system on DLISP, which I think would accomodate
*-*-* just this sort of perusal.
The output of retrievals should be filterable by attributes so the user sees
only the part of the item he/she wants.
*-*-* The (weak) user model can house just this sort of information;
*-*-* which the retrieval functions can use.
The output of retrievals should be divertable|spliceable to hard-copy devices.
*-*-* No comment.
Transcripts of sessions with the system should be savable (non-trivial if
some input is from analog devices and some output is graphic).
*-*-* No comment.
All retrieval concepts involving pointers-- e.g., find every item of type
'planstep' that DEPENDS on an item with keyword 'rain'-- should be defined
in terms of a few primitive operations for traversing networks and should
be modifiable/augmentable by the user. The definition language should
allow specification of the distance between the items, the pointer types
required for the concept, and the pointer types that disallow the
concept.
*-*-* This is right up RLL's alley. Much of my time has been spend defining
*-*-* easy means for just this sort of transversal.
The system should have an interface for inspecting and modifying its
components: retrieval concepts, output filters, default input modes,
and any other parameters. This interface should be uniform with that
used to inspect and modify the item database wherever possible.
*-*-* 100% agreement. Every part of the RLL system is (or will soon be)
*-*-* this transparent, and modifiable. The only disadvantage of this
*-*-* approach is the non-trivial start-up time; from then on the wins
*-*-* are tremendous.
---------------
*-*-* I did want to conclude by explaining many of the hedges you
*-*-* may have noted above -- RLL's big plus is NOT its current selection
*-*-* of currently implemented features; rather, it is its abundance
*-*-* of available hooks, which permit it to readily code up those
*-*-* particular components.
*-*-* The fact that many of the things mentioned above do not now exist
*-*-* is not a serious limitation -- it only reflects the fact that I
*-*-* have not needed those facilities.
*-*-* I do welcome the opportunity to enhance
*-*-* the RLL system by coding up these additions...
*-*-* As with any new code there is the obvious problem that it will be untested,
*-*-* and possibly do the wrong things.
*-*-* I think the RLL-coding-style, which insists on making things explicit
*-*-* whenever possible, does lead to less buggy initial code.
End of pep talk. If any of my claims above seem outlandish, or simply untrue,
please let me know. (I've been known to exaggerate before.)
Russ
∂29-May-81 0937 RICK at RAND-AI rll
To: greiner at RAND-AI
cc: rick at RAND-AI, rdg at SU-AI
∂TO RICK@Rand-Ai 18:17 29-May
RLL revealed!
Russ:
I've now read the rll papers you gave me and I'm impressed.
Now I have some questions.
(1) How do you do unit-to-disk and v.v. swapping?
Specifically, how efficient is the indexing and loading?
What makes for efficient retrieval of units?
*-*-*
[Does "v.v." stand for vice versa?]
The basic swapping is performed by a package Dave Smith wrote called CORLL.
(I'll send you a manual at first convenience.)
The basic accessing functions all check first to see if the unit
in question in currently in core (as this is the assumed standard case),
reading that unit in only if necessary.
Units are swapped out, using a simplified LRU scheme, during certain
garbage collections, under certain conditions.
(Dave is just now converting CORLL over to use IL's HASH package,
rather than the one he wrote, by the way. I think this will make
the accesses yet faster, and require less space. We'll see...)
The only retrieval key for a unit is its name. If you want a more
versatile scheme, I imagine it could be written up in a day or two.
*-*-*
(2) Can we handle upto 3000 units in RLL? Can we feasibly
use RLL for plan rationale items, one per unit. How efficient
would it be to store text strings of several hundred characters
within a slot of a unit?
*-*-*
RLL currently handles about 1000 units, with no problems.
Yes, each rationale item does deserve a unit; and I believe RLL could
accomodate that without any trouble. It was the keywords I was
worried about. RLL may have a hard time holding a large subset of the
English language in "core". Of course, this is only necessary if my
ad hoc scheme is used -- and seemed a strong reason to reject that
approach.
I think the limiting factor will NOT be CORLL -- it makes the storage
limitations about the size of disk, not IL's 256K.
Rather, IL has an inflexible upper bound for atom names, of 32K.
While we're still a long way from that, it may take some tricks
to sidestep this problem. Mark Stefik's LRS system allows units
to have numeric "names" -- like (Transistor . 45). I imagine CORLL
could handle that without too much fuss. (After all, names like
R-342 are essentially isomorphic to that.)
Text strings - here I don't know. Yes, you could store them, no problem.
However, we're at IL's mercy when it comes to retreiving them, depending
on whether that space is reusable (atom name space is NOT). If not, we may
be able to sidestep that problem by keeping that english text on some external
file, out of IL's jurisdiction. But let me first check -- this contortion
may simply not be necessary.
*-*-*
(3) Is RLL mature enough for me to consider using it for the
project?
*-*-*
Believe it or not, I think so. It seems to have attains a nice
degree of sturdiness (as opposed to fragility), at least for all the
tasks I've assigned it. Yes, several things will have to be added on;
but most of that will be, little more that LISP coding.
Those parts which only RLL can provide are, I feel, fairly complete.
Anyway, I will certainly be available to provide both quick patches
and, after consultations with experts like yourself, appropriate
alterations to underlying code, as needed.
It would be a good test of competence, for both RLL and me.
My response to Keith's letter should indicate some of my beliefs
and convictions, and may give clues about RLL's readiness.
*-*-*
-----
Anyway, we should continue to discuss this, as I do not want to be
in a critical bottleneck in this overall project; especially as
thesis time rolls around. Let me outline what I would consider an
ideal scenario, should RLL be used:
(i) I would first provide the necessary "indoctrination" into
the use and style of the RLL "way of life".
(I did personally thank Stan for that useful insight.)
(ii) As we collectively designed the overall system,
I would show how RLL was actually encoding the various different parts.
At least at first, I would remain visible, to fix up breaks
(which, sigh, I know will occur,)
hopefully with some recent initiates looking over my shoulder.
(iii) After not too long, (pessimistically a month,)
this RLL system can be pseudo-frozen. (IE only changed as necessary to fix
major implementation bugs -- not design/conceptual errors made earlier.)
Here quantities of data can be dumped in.
While remaining on emergency call, I can beg out of this aspect of the project,
to work on other parts of it, or thesis sorts of stuff, or whatever.
(iv) After a few months, there will undoubtedly be realizations
of shortcomings of this implementation of the workbench.
Here the now experienced RLLers and I could collaberate to reconfigure
the system into the improved second release.
(v) From here on I think I will be expendible. By now Rand will have a
slew of artists who can use and expand their RLL environment, and provide
contributions to the RLL community. (Sounds like Mom and Apple Pie, don't it.)
-----
[I should make explicit one of my biggest worries: Although my ego is
somewhat tied up in RLL, my thesis will not be. There may be extended periods
of time over which I will have other higher-priority (ie thesis-related)
concerns; and here I would prefer to feel comfortable packing off from this
project. Now I do think I can become gradually less needed -- there's
not all that much to RLL itself, beyond the rll concept.
Once that is communicated, the existing code is fairly straight forward to
understand, and the future code can be as easily incorporated.
Or at least that's my current work hypothesis (no pun intended).]
Russ
∂29 May 1981 1322-PDT RICK Today's design contributions
To: wescourt, bill, greiner, randvax!norm at RAND-UNIX, randvax!barbara at RAND-UNIX
cc: rick
GUIDELINES: KISS, ONION (incremental developments)
THINGS TO DO:
Elicit/Enter new items
Display
Edit/Alter
Historical change/update/feedback
Analyze/verify/re-verify/hypothesize
Interrogate: What specifically for replanning?
Brief
WHY DEMONSTRATE?
1. We need to sell our work
Graphics good for this
Analysis capability good for this
2. We need it for experimental & conceptual development
This motivates edit, display and hardcopy capabilities
In support of brief, interrogate, and elicit capabilities
3. We need milestones
Should be realistic, achievable, incremental, satisfying
4. We need it for project management
This motivates display, update, ...
5. We need to communicate to outsiders
POINTS TO DEMONSTRATE:
1. Recognizable problem/scale/realism
2. Improved approach/techniques/already done
3. New capabilities/science/already established
4. Specific promising avenues of further R&D/worthy of R&D support
5. Applicability in near team/worthy of operational support
IMPLEMENTATION ALTERNATIVES:
Case 1: Continue as much as possible with VAX/UNIX/C
Pro:
Existing software
Norm comitted
Good editor
MH candidate
Everyone knows E & MH
UNIX has good software tools
Carries forward into other unix machine environments (or ADA)
We learn unix
Con:
Software modifiability low
Only norm is an ace
Analysis is difficult without evaluable expressions
Software must be designed before implemented in C
Norm worries about graphics => no one else to program text part of WB
Case 2: Move as much as possible to a collection o ROIE programs on the 20
Pro:
3 very good programmers+BHR possible
I'm sure much of it can be done well in the language
Frees norm for graphics
Good editor & possibly Hermes & SPELL & PCL
KW knows lots of the 20 software
Carries forward into the dolphins nicely
Con:
Very slow for large databases
Would probably have to implement indexed/swappable units OR
woul have to use many fils
Probably wouldn't be practical without IPCF capability which isn't
expected until Sept
<= multiple rosies
<= memory limits on rosie
Relational language is quite hard to do in ROSIE
Evaluable expressions hard in ROSIE
Case 3: Move to RLL (with INTERLISP)
Pro:
Can handle all items in its own KB
Can handle relational language
Should be possible to couple a front-end to RLL from ELLIE
for many interactions
Russ is an ace on RLL
Dependency maintenance should be easiest in RLL
Frees Norm for graphics
Con:
Doesn't support strings & string matching well
Who can understand it? --> Rick (.7), KW (.7), RDG (.95)
BS is willing to learn it
Only Henry knows ELLIE, but KW should know it too
Very risky, because we don't know we can use it effectively
Makes RHR responsible for lots of software
Case 4: Do a mix of C & ROSIE
Pro:
Rosie can run c programs via arpanet
Each person can program
Con:
Requires arpanet & lots of pattern matching by ROSIE which is slow
Case 5: Mimic small-talk <e.g., use simula>
Pro:
Prepare for small-talk as the eventual RIGHT language
Good for long term if we stick to this software base
Con:
Lots of additional work required now
Much less to demo by September
Bad for long term if we suspect we'll drastically change our
software later
APPARENT NEEDS IN PRIORITY BEST APPROACH APPARENT COST
1. Graphics display NS/BS/MW: done in C NS all summer
1.1 Networks Genisco or AED
1.2 Highlight dependencies
1.3 Hardcopy plans I like BHR ideas
1.4 Hardcopy rationales ditto
2. Analysis RHR all summer
1.1 Automated value changes RHR/KW:RLL or ROSIE Need multiple DBs
1.2 Constraint propagation ROSIE=>major changes
1.3 Manual traversal Tight couple to graphx for unevaled exprs
(pass item names) Duplicated DB on VAX
3. Entry/editing/maintenance KW/NS: PCL,ELLIE,EMACS KW all summer
Parse to produce items
in different formats
Translation between user
form and RLL/ROSIE/UNIX
inputs
4. Retrieval/Question Answering BS/BHR: ROSIE or RLL BS all summer
Develop plan KB and index
Minimize string searching
Employ new interlisp string
matcher from KW where needed
5. Briefing BHR/RHR: ROSIE BHR all summer
Develop plan hierarchies
Develop interestingness
Locate interesting elements
INTERMEDIATE MILESTONES:
Fri 5 Jun Initial mgt plan prepared
Tues 9 Jun KW formats the mgt plan & distributes it
Fri 12 Jun Each person brings a concrete illustration of his part
Fri 19 Jun Each person brings a concrete design for his part
(that can be done in 1 month)
Fri 24 Jul Initial implementations demonstrable
Fri 31 Jul Revised designs for 1st functional system
Fri 14 Aug First functional system
PRIMITIVE SYSTEM ELEMENTS:
RETRIEVAL: <item descriptions>+<indexed retrievals>
language, linguistic generality;
relationships among items
STRUCTURE: <relational language>
types of relations, pointing to items, formation/alteration
copying sub-structures
intra-item variables
inter-item constraints
GRAPHICS: windowing
zooming <descent,ascent, scale change>
clipping
boxes, links, labels, content
DEPENDENCY MAINTENANCE:
ramify constraints
detect inconsistencies
try to solve constraints
-------
---------------
-------
∂TO Barbara@Rand-Ai 12:36 4-Jun
Response to Barbara's comments
*** I apparently didn't ruffle any feathers enough to get
*** any other response to my last message, besides yours.
*** Did you mail that set of comments (your response to my message) to the
*** other group members? If so, please feel free to forward
*** this reaction to them as well, if you think it would be relevant...
wrt 2)
The protocol contains some instances of well-structured
arguments of the form: Premise A, Premise B, ..., Therefore Conclusion.
In other cases, a statement in the protocol is supported by a list
of more or less independent reasons. Some statements benefit from both
types of support and there are probably others as well.
In any case, we might want to explicate the nature of the argument
underlying a particular statement and the exact
relationships among its constituents.
Yes, I heartily agree there are many other types of relations
beyond those few I mentioned.
In particular, there were many times
when a whole slew of independent
things were needed to reach some conclusion --
ie instantiated your first sub-example, Structured arguments.
(I remember noting how woefully awkward the proposed slot-based
formalism became in such situations...)
In all those cases the relationship joined a
n-1 tuple of premise rationales with a concluding rationale.
[Q: Are there other cases?]
Clearly there is some type of inferencing going on in this situation.
I would feel uncomfortable unless such rule(s)
are explicitly stated.
(For example, the rule might be modus ponens;
or it may be some user based deductive scheme.)
[Q: Do others agree such rules should be explictly stated?]
In these situations perhaps we should play theorem checker (ala FOL),
and force the user to indicate how each deduced statement was derived,
and from just which premises.
If so, we should begin to define his (starting) vocabulary of allowed
operations. (which should certainly include at least the logical set
FOL gives -- eg And-Introduction, ForEvery-Instantionation, Modus Ponens.)
He should be able, eventually, to define his own -- using, perhaps, his
own ideas of "proof".
(This does lead to one important worry:
deductions may no longer have the nice property of being purely syntactic.
Of course, this may not be much of a loss,
as that derivation process was always intractable anyway;
and we never `really' intended the Workbench to work unassisted, and ...)
Realize that then the second example,
Example: Domain-specific functional relationships
Resource requirements are a major consideration in the bike trip plan.
It might be useful to code them explicitly so that we could easily
answer questions like--How much money does Norm need and which parts of
the plan require cash?
becomes essentially a special case, once we have a handle on inferencing --
ie a set of rationale can be used to "prove" a concluding
rationale, based on a user defined inference rule.
(eg the "resource allocation rule" would be called to justify the conclusion
"Norm must have money" whenever the "Norm might need to spend money" premise
occurs.)
Proposal: (<= read unsubstantiated first thoughts)
This capability might be implemented by simply considering
each jump as "application" of a lemma
-- ie this conclusion does follow logically (ie using only the
initial operators) from the premise, but as that process takes several steps
we encoded it into a single rule.
That user-defined operator would then be just a "macro", which, when
instantiated by the premise, returned the conclusion.
(Note it may have to check a set of assumption along the way...)
This lemma-idea is certainly true in some cases
-- such as the one trivial example shown above.
Other cases might involve, for example, non-monotonicities;
and so could not have followed
(first-order, domain-[as opposed to meta-]level) logically.
Hence, to be as general as we would like, these lemmas may have to be in
some higher-order logic.
(This will assuredly force us to worry about reason-maintenance at various
levels -- with all the problems that involves...)
Comments/refutations/screams of anguish?
wrt 3)
As I understand your approach to this problem, you are trying to
enumerate a "complete" set of relationships, capable of capturing
everything planners might express during a planning episode.
Another approach would be to enumerate those relationships that
would provide useful functions during plan review, plan evaluation,
plan modification, etc. What functions will the relationships you proposed
provide? What questions will they answer?
How will they help somone understand or use the rationale?
Several comments:
i) Actually I was just reacting to the way the plans were displayed --
I felt that just indentation, by itself, could not possibly convey
all the facts necessary for understanding a plan.
It is possible, for various psychological-type reasons,
that that type of listing may still be the best hardcopy form for
presenting the plan to a user. However I feel the user should be able
to determine why a particular UNDERLING fell under a HEAD -- just how
they were related.
Before we can store such information it is essential
to at least map out the space of possible relations.
That list I mailed was
designed to be a first crack at that categorization --
an ennumeration of the diverse set of things one may want to use in
connecting two rationales...
ii) No, I never felt any such list will be sufficient to capture *everything*
any planner would want to express.
I was hoping only for a good working subset.
My philosophy is to provide the user with two things:
First, that almost-spanning subset, including relevant
terms, connective, inference schemes, etc.
Second is a set of mechanisms, which can be used to
help those future planners to expand that pre-existing vocabulary
into the one he wants to use.
I'll come back to this point again in "wrt 6)", below.
iii) This does lead to the question of what would constitute a good
initial collection of connectives.
For this I need the data which will come from the replanning experiments
you're now performing. Any word on when such output will filter out to
me here? The data I'm collected thru introspection alone I'm found to
be too limited.
wrt 4)
I'm quite willing to make lexical substitutions in favor of conformity.
Which terms should I redefine/incorporate?
wrt 5)
Another useful "time" (in addition to plan generation and plan execution)
is plan modification time. How do we keep track of successive states
of an evolving plan and their relationships to one another?
This is a good point - Keith, in his recent message, was clearly quite
concerned that the history of a plan's derivation and modification
be preserved.
This is a meta-level connective, pertaining not to the plan per se,
but rather to the planning process, and the planners themselves
-- their oversights, ignorance (eg about faulty tacit assumption), etc.
[Notice that the plan execution time links are not really meta-level facts:
Yes, each is based on the implicit meta-level assertions that
"the planners do not know some X", but that "X will be known later".
(where X is some proposition, such as "Norm <is> tired at 4:20PM on Feb 3".)
However one could say the same (vacuous) type of thing about the plan
generation time assertions -- namely that "the planners do know that X",
and used it to formulate this part of the plan.]
Anyway I agree these links should be preserved -- but I reiterate my point
that they need not be stored in the same manner that is used for standard
links.
(This is a subtlety to this point:
The "PlanStep#4 was replaced by PlanStep#4'" link is such a meta-level
connection, and need not ever be visible to anyone examining the final plan.
However, the facts that
"PlanStep#4 looses BECAUSE of fact X",
"PlanStep#4' is immune to the effects of fact X",
together with the (implicit or explicit) marks that
"PlanStep#4 is IN",
"PlanStep#4' is OUT",
are useful, and should remain.)
wrt 6)
General issues of timing planned actions are apt to be more complex than
"before," "after," and "until." Consider: at 5:00, during the ascent,
within 60 seconds of landing, for at least two hours.
Yes, time is a complex beast. So is space (as in spatial relations),
intentions, and naive physics (ie enough [?superficial?] understanding of
how things interact to get by in the world).
I personally feel the "right" approach is to provide the
user with a host of pre-defined terms and relations which we (the Silicon
Pencil's designers) happened to feel were natural, and, for our tasks at
least, sufficient.
Clearly many of these "domain independent" things
should be in the domains mentioned above.
Of course the particular things we provide are guaranteed NOT
to correspond to the user's intuitions.
This is why I believe it is important to give the user the tools he will
need to construct his own parts, or "twiddle" those parts we provided.
Those initial peices are only there to give the user a flying start.
-----
Anyway, I may have oversold a bunch of claims above...
While I do feel the eventual, mature system should have these sorts of
capabilities, certainly many of these attributes can be omitted in the first
few implementations; as long as we can add them on later, as need arises.
My major point is that we keep these ideas in mind throughout our design,
so such upgrading are easy to perform.
[Hmm -- none of the various lists include the planning idea of
"background ideas/motifs". Any ideas on how to incorporate this?
(I know Wilensky has given a bit of thought to this point recently...)]
----
Russ
∂ 4 Jun 1981 1036-PDT Keith Wescourt <WESCOURT> Re: Comments on Keith's Proposal
To: Greiner
cc: Bill, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
Russ,
Sorry to take so long in responding to the thoughtful annotations
you provided to my proposed list of features/capabilities for
the Workbench-0 design. In the interim, some of these,
especially those involving access control and "edit histories"
have been deferred to later implementations of Workbench. I am
currently focussing on our plan/design for user entry and
modification of items in the Workbench database. As a result of
conversations with Rick and your comments on my initial proposals
my current planning includes a role for RLL (and IL). I am
working on the details now and your comments are serving to guide
my decisions about which functions I should expect to be
able to use RLL for. They have also caused me to place learning
RLL on my personal agenda.
When is your next visit here? You and I should plan to spend
some time in a one-on-one meeting then. You will have access to
my current planning before then, so you can think about it before
we meet.
Keith
-------
∂19-Jun-81 1236 RICK at RAND-AI revised retrieval specifications
To: rdg at SU-AI, wescourt at RAND-AI, rick at RAND-UNIX
cc: rick at RAND-AI
0<RICK.PLANNER>RETRIEVAL.TODO.1 18-Jun-81 13:26:00, Edit by RICK
Things for Retrieval to do/IO specifications
Inputs that change the database
User-prerogatives:
Different users have specific rights to change kinds of
values
One kind of prerogative is the right to change item prototypes
From retrieval:default attributes for items of certain characteristics
automatic addition of pointer inverses
other consistency checks
defaults for particular users
From entry:
Enter new items
(CreateItem <proplist>)
<proplist> ::= () | (<attribute-val>..<proplist>)
<attribute-val> ::= <predef-attributes> | <undef-attributes>
<predef-attributes> ::= POINTERS <ptr-item-list>
| DESCRIPTORS <self-desc-list>
| KEYWORDS <phrase-list>
| HISTORY (<past-item-id-and-reason> <future-item-id>)
| STATUSES <status-val-list>
| ITEM←TYPES <type-list>
| NAMES <phrase-list>
| VERBATIM <sent-string>
| SYNTAX <case-frame-parse>
<undef-attributes> ::= <attribute> <value>
<self-desc-list> ::= UNIQUE←ID <item-id>
| CREATION←DATE <creation-date>
| CREATOR <creator>
<past-item-id-and-reason> ::= (<item-id> <reason-for-change-item-id>
| NIL
<reason-for-change-item-id> ::= <item-id>
<future-item-id> ::= <item-id> | NIL
<ptr-item-list> ::= () | (<pointer-val>..<ptr-item-list>)
<pointer-val> ::= <pointer> <item-reference-list>
<item-reference-list> ::= () | (<item-ref>..<item-reference-list>
(item-ref> ::= <item-id> | <item-get-fn-entry> | <item-get-fn-ret>
<item-get-fn-entry> ::= (ENTRY <retrieval-spec>)
<item-get-fn-ret> ::= (RETRIEVAL <retrieval-spec>)
<status-val-list> ::= () | (<status>..<status-val-list>)
<status> ::= IN | OUT
<type> ::= REASON | GOAL | PLAN←STEP | SPECIFICATION | DEFINITION
| ASSUMPTION | REJECTION
<phrase> ::= <regular-expression>
<case-frame-parse> ::= <recursive-property-list-of-parse>
[Multiword-atoms formed with underbars for space]
[Case decisions: input case preserved; retrieval ignores case]
Name
Attribute-values
Short printnames
status,itemtype,
descriptors (creator,date)
Text
String, parse case frames
Constraint equation
Pointed-to-items
Parameters/variables
Indirect references to items or elements of items
Immediately evaluated
Evaluated at retrieval time
Edit existing items
New version of the item
Relationship with previous versions
From Analysis:
Edit existing items (as above)
Inputs that request info from the database & outputs desired
From entry:
Input= <reference> is description of desired item
+ <desired elements>
Output = a list of ((item id, (desired elts of that item))...)
Special kind of <reference>:
All items which are in some role in some relation
(e.g., the dependent on a transitively closed inv-pro)
[Can't currently say to the syntax]
(Extract <item-spec-list> <extraction-schema>
****----****
Find <item-list> <match-spec> --> <item-id-list> [subsets the list]
Ramify <item-list> <relation> <closure-operator> --> <item-id-list> [new list]
Extract <item-list> <schema> --> <extracted-item-list>[gets att-vals of items]
<schema> = attribute-list
<item-list> ::= all-items, item-id-list
<match-spec> ::= boolean-combination-of-primitives
<primitive> ::= <element> <match-op> <term>
<element> ::= <attribute> | <ptr>
<match-op> ::= INCLUDE | INCLUDES | MENTION | MENTIONS | = | ~=
all-plan←steps, plan←steps whose date < 14 apr 81
[[match-spec itself must allow recursive specification]]
[[current syntax probably doesn't allow correctly]]
find all-items whose (pro items)'s keywords include norm
Entry produces item references both from syntax & from user requests.
Here are the kinds of references the syntax of items supports:
<elt-of-ref>is description of infor desired from desired item
<reference> ::= # <quant> <item-type> [WHOSE <element>
<match-op> <term> {<conj> WHOSE <element> <match-op> <term>}]
<elt-of-ref> ::= [<quant> <element> OF] <reference>
<match-op> <term> {<conj> WHOSE <element> <match-op> <term>} ]
<element> ::= <attribute> ATTRIBUTE | <ptr> ITEM
<quant> ::= EVERY | THE
<match-op> ::= INCLUDE | INCLUDES | MENTION | MENTIONS | = | ~=
Examples of syntactic references and elt-of-refs
[the following now parses]
the keywords attribute of every item whose keywords attribute include norm
[the following do not now parse, but probably should]
the keywords attribute of the item whose pro ITEM mention [*]any person
... [*] has a subject = Norm &
has a verb = does travel
every item whose pro-1* item = item 2901.1
[asterisk here means transitive closure; what about "+" ?]
∂23-Jun-81 0647 rick at RAND-UNIX overall design and components plus interfaces -- discussion notes
Date: Tuesday, 23 Jun 1981 06:32-PDT
to: planner at RAND-UNIX, rdg at SU-AI
SUBJECT: overall design and components plus interfaces -- discussion notes
Item-type: Specification
Status: In
Pro: these concepts were discussed in the meeting on 22 jun 81
Pro: this design uses independent modules mediated by retrieval, each
providing its own user interface
Con: Norm thinks there should be a uniform interface to the workbench
Pro: rick thinks the initial workbench need not have a uniform interface
and that a uniform interface would take 6 months to develop
From: rick at RAND-UNIX
The major components of the workbench identified were:
1. a selector (switch) at the user interface on TOPS20 that selects
one of the other modules for use by the user
2. entry (for creating and modifying plans)
entry sends create-item, modify-item, and retrieve-item
requests to retrieval
3. briefing
4. analysis
5. query
6. grafix
7. retrieval (plus database)
Two other components that were identified but whose implementation remains
unclear include:
8. user profiles
9. concept database (a taxonomy of concepts used by various modules)
We decided that these two components may either be implemented
within the separate modules that require them or may be added to the
specifications for entry and retrieval and database if they seem
generic to workbench applications.
We discussed the three-basic functions of retrieval, FIND, RAMIFY, and
EXTRACT, and clarified the need for recursivity (of find/ramify specs)
within any find request. An example of such a recursive find request might
be "Find every item whose keywords include "John" and whose Pro items
have (status = OUT and con items who have (...))". The syntax for
recursive find-specs needs to be done and so does the mechanism for
database searching.
We agreed again that each person on the project has primary areas of
responsibility which cover all possible tasks within that area. Therefore,
each person may be requested by others to implement capabilities they need.
Discussion with Norm - 19 June 1981
Norm wants to store a several specific graphics-related pieces of information,
and be able to retrieve such data, on demand (during this, or subsequent,
editing sessions).
In his model, such information will go thru ENTRY (read Keith's
routines) -- at which stage they might be augmented or enhanced.
[?Keith - do you agree?]
I've listed below the types of data which seems necessary, followed
by a scenario overviewing the sort of interactions which use such facts.
This is followed with a proposal for the interface, and finally, with
a few outstanding questions.
-----
1. A (weak) user model -- to indicate which set of colors should
be used; or what types of lines to use for CON links during a demo.
These facts would be used to answer a limited set of questions about
this user's preferred (or default) settings for various parameters.
In addition to standard sorts of people - like Bill or Russ - it will
house info about "Generic individuals", such as the TypicalUser, or
TypicalWBHacker.
[Keith - you might use this set of units to store "verbosity", ...]
2. Facts about the actual displays --
That is, we need functions which return (pointers to)
the actual translation tables for a display.
This function takes 3 arguments:
the particular monitor being used,
the environment (this includes LightSetting, Time Of Day, and who knows
what else),
and the "effective user" (eg DefaultUser, or Russ, or Demonstatee - see 1.).
Proposed algorithm to find the entry (translation table) that matches
this particular set of parameters.
i. See if there is currently an entry which equal these parameters
(eg do a simple look up).
ii. See if these is a default setting for this monitor and user (ie
ignore the environment).
iii. See if this monitor has a default setting (ignoring user and environment.)
iv. Use the absolute default table.
(all of this comes almost for free using RLL's defaulting mechanism...)
3. Data about drawing lines -- such as
Red is row 37 of the translation table.
Deny-Lines are Maroon, and Blink, and are NOT Dashed.
IN-Links are drawn as Assert-Lines.
4. Some "Display Facts" about the ITEM nodes -- eg that X and Y should
be "at the same level" (read same Y position); or that X should come
before Y (to its left) when printed.
------
The data flow would be both ways -- GRAFIX would, on occasion, state
that "the user says this setting is good", but more often it will be
asking for data. In case (i) RETRIEVAL will store this table-setting;
to be retrieved as need arises. (Note ENTRY or someone will have to know
the current setting for the environment (eg current absolute time, and
total session time so far) and the user.
[?: Can I infer facts about more general classes of users, (eg WB-Hackers)
or just this specific one, (here Russ)?]
------
Scenario:
A)
Grafix - Entry: I need to draw a CON line. What color should it be?
Entry - Retrie: (FindGrafix (Color CON))
Retrie - Entry: Who is the user?
Entry - Retrie: Rick
Retrie - Entry: Row 37 of translation table
Entry - Grafix: 37
B)
Grafix - Entry: This setting is good! - 100101101...
Entry - Retrie: (StoreTable 100101101... (Russ (2:13 19:43 ...) Mon#3))
Retrie - Entry: Done.
C)
Entry - Retrie: (NewUser Norm)
Retrie - Entry: (NewTable 101001111....)
Entry - Grafix: "101001111..."
-----
At some point Keith & I should define a syntax which permits new facts
to be stored about (non-item) objects. For example,
(CreateObject Russ (Isa (Person) LikesColors (Red Green) ...))
(CreateObject Chartuese (Isa (Color) SimilarTo (Blue Green)
RowInTranslateTable 103 ...))
...
(ModifyObject Russ (LikesColors (Green) HatesColor (Red)
Nuances ((PleaseAvoid Blinking) (Be concise))...))
...
Or course data will have to go the other way:
(FindGrafix (Russ LikesColors)) - this would return (Green).
You get the idea. (Comment: we will probably need this sort of
fact-passing for general objects, anyway -- eg to assert facts
about Hilliness (eg it is the antonym of Flatness, and relevant to...))
Anyway, Keith, Norm and I should get together to figure how we should
communicate amoungst ourselves -- eg should I say
(TellGraphics (Table "101100001..."))
and if so, how will Keith further this to Norm?
-----
Other remaining issues:
Must I go thru ENTRY to contact GRAFIX; and vice versa?
Who should be responsible for storing various session-dependent facts?
I'm assuming RETRIEVAL (ie RLL) will house all permanent facts --
that is, things to be used from session from session -- but there
are many facts which pertain only locally, and only to this editting
session. Should RLL store these, and force ENTRY to request such
data every time? Or should both of use keep copies of such facts?
Or, as the scenarios above assumed, leave them only with ENTRY?
Should the user have any direct say in these screen-related matters?
For example, that he'd rather see OUT-Links as Magenta (skipping
a few levels), or (addressing the more general issue of user
profiles:) that he no longer thinks of himself as a novice, and
could ENTRY please stop talking down at him, etc.
-----
These are sloppy first guesses at solving a number of these issues.
Comments from other people people on these proposals will be greatly
appreciated.
Thanks,
Russ
-------
∂TO Keith, Greiner (12:05 29 June)
Data for Retrieval
Keith -
I'm all set to start coding the level-0 implementation of
the "retriever", and now need data to work on.
Rather than cons-up some random examples, I figured I'd snatch some of
the existing messages now in workbench, massage that into a format
corresponding to our interface agreement, and store that sort of stuff.
Unfortunately that lacks things like the parse-tree, and keywords, ...
The other problem is I don't really know what sort of inquiries will
be made, into this DB.
So now the question: Have you already made up such a file -- consisting
of a string of commands of the sort Entry would send to Retrieval?
If not, could you create such a file, which I could use for my design?
-----
That file could be in the format
(CreateItem (TYPE REASON STATUS IN KEYWORDS (Fred Mary) ...))
(Find ALL-ITEMS (AND (EQUAL STATUS IN)
(EQUAL TYPE REASON)
(INCLUDE KEYWORDS Martha)))
...
Thanks,
Russ
∂29-Jun-81 1259 Keith Wescourt <WESCOURT at RAND-AI> Re: Data for Retrieval
To: RDG at SU-AI
cc: keith at RAND-AI, greiner at RAND-AI
In-Reply-To: Your message of 29-Jun-81 1205-PDT
Russ,
I'd like to oblige you, but am doing my own coding/example generation
for the input syntax. We've all agreed that everyone should make
up their own test data for now, so I'm afraid you'll just have
to fake it from the existing items on the VAX even if they don't
have parse-tress, keywords, etc. I don't think that anything
ENTRY will be send you for retrieval purposes will key on parse-trees
anyway. FGor purposes of testing you should add keywords, etc
to your test items as you see fit-- imagine the types of references
to existing items you would like to make if you were entering
a rationale...
I'll let you know as soon as I have something you can use. Right
now I'm still trying to define and implement a parsable input grammar
using ELLIE.
Keith
-------
<reread>
∂16 Jul 1981 14:53-PDT preliminary database specifications barbara at RAND-UNIX
Item-type: Specification
Status: In
Succeeds: item 186
Pro: this item incorporates information about the master plan item
To: planner at RAND-UNIX
the database contains two classes of items, plan items and rationale items.
plan items describe elements of the plan. rationale items describe
elements of the rationale. additional description and specifications for
each appear below.
plan items:
there is a master plan items that subsumes (via the sub pointer) all
other plan items.
other plan items represent each of three different types of plan elements,
goals, specs, and tasks. goals are the motivations, objectives, and
guiding philosophies of the project (e.g., develop an impressive demo by
september 1, build the demo around a real problem, KISS, ONION).
specs are system specifications, that is, functional descriptions of
the components and sub-components of the system we will develop to
satisfy project goals (e.g., analysis, graphics, briefing, briefing
a project leader, briefing a project leader on the plan). Tasks
are the activities project staff will carry out to implement specs and
achieve goals.
plan items form a basically hierarchical network with the master plan item
as the highest-level node. it has three immediate subordinates, the
highest-level goal item, spec item, and task item. (this means that each
type of plan item must have exactly one highest-level item, namely the
one whose -sub is the master node.) the remaining goals of each type
form roughly hierarchical sub-networks under their respective highest-level
items. the network is only basically hierarchical because some items
can be sub's for more than one higher-order item. also,
arbitrary pairs of items may be related via dep, req, and alt pointers.
plan items comprise the following information:
content: subject
author
label (for graphics <= 20 chars)
syntax
text
attributes: class: plan
type: master/goal/spec/task
status: in/out
staff: [responsible staff designators] (optional)
budget: [$ or name-days?] (optional)
resources: [equipment, other?] (optional)
due: [date] (optional)
done: [date] (optional)
pointers: sub[ordinate] (points to other plan elements of same type)
-sub (inverse of sub)
alt[ernative] (points to other plan elements of same type)
-alt (inverse of alt)
req[uirement] (points to other plan elements of same type)
-req (inverse of req)
cor[outine] (points to other plan elements of same type
dep[ends on] (if type = goal, points to specs or tasks;
if type = spec, points to tasks
if type = task, no dep pointers)
-dep (inverse of dep)
pro (points to reasons)
con (points to reasons)
Note: sub & -sub define the plan element "hierarchy"
alt, req & -req, & cor further relate items within a hierarchy
dep & -dep relate items representing two different
types of plan elements
pro & con relate plan items to rationale items
(and rationale items to one another)
rationale items:
rationale items represent each of three different types of rationale elements,
reasons, assumptions, and rules. reasons are the immediate justifications for
particular plan items (e.g., the KISS heuristic is a prerequisite for
r&d success). Assumptions are the beliefs, facts, data, etc.
uncerlying particular reasons or underlying other assumptions or rules
(e.g., the hearsayII project used the
KISS heuristic). Rules are the methods by which assumptions are
used to infer reasons, assumptions, or other rules
(e.g., if many successful r&d projects used
heuristic h, h is required for r&d success).
the rationale items should form multiple hierarchies. the highest-level
node in each hierarchy is the plan element being rationalized. it
subsumes a number of reasons via pro and con pointers. these, in turn
subsume assumptions and rules via pro and con pointers, and so forth.
rationale items comprise the following information:
content: subject
author
label
syntax
text
attributes: class: rationale
type: reason/assumption/rule
status: in/out
confidence: certain/confident/believe/doubt/deny
pointers: pro (points to supporting assumptions and rules)
-pro (inverse of pro; n.b., if type = reason, points to
a plan item)
con (points to contradicting assumptions and rules)
-con (inverse of con; n.b., if type = reason, points to
a plan item)
∂24 Jul 1981 1112-PDT <WESCOURT> Re: Minor changes to Entry/Retrieval Interface Specification
To: GREINER
cc: rick
In-Reply-To: Your message of 23-Jul-81 1211-PDT
∂ 23 Jul 1981 1211-PDT GREINER Minor changes to Entry/Retrieval Interface Specification
To: wescOURT
cc: greiNER, rick
Greetings! How is ENTRYing going?
I've implemented a parsable syntax in Ellie. It still has a few glitches
handling compound relative clauses, but I'm passing them over to
work on the semantics of the productions-- i.e., building the CreateItems
sentences for you.
I'm starting to get the retrieving to turn over; and have some small
proposals to proffer:
1) It might be easier to send several new items at once -- using a
CreateItems function. Inverse pointers, and other KB maintanence will
be performed at the conclusion of creating all the items. See the file
<core>To-Retr.From-Entry to see examples of this.
Yes, I'll be parsing a "buffer" full of items at a time and won't "send"
them to you until they all parse correctly.
2) As RETRIEVAL is ultimately responsible for giving each item a unique
id, it seems silly for ENTRY to send along (what it claims to be) a
UNIQUE-ID. However it certainly is convenient to have such a handle,
to tie things (sent together in a CreateItems command) to one another.
For this purpose I propose ENTRY automatically send along its ENTRY-ID.
The "acknowledging" value then returned from the CreateItems will then
be an alist (or plist if you force me) of the form
((entry-id1 . unique-id1) (entry-id2 . unique-id2) ...(entry-idN . unique-idN))
and ENTRY will be expected to use these Unique-Ids from now on (ie
there seems no advantage to preserving these non-unique entry-ids after
this command).
Exactly. I proposed that the ID's I would be sending you would be local
to the buffer of parsed items sent at any one time. I want to use them
as the values of pointer attributes between those items in the same buffer.
The unique ID you generate will serve the same function for pointers to
items already in the database.
3) We need to establish some "quoting" conventions -- to determine whether
the values of a given attribute should be taken as is, or evaluated
at item-creation time.
It seems most POINTER values should be evaluated, and, in most cases,
all the other values should be just accepted.
I've begun to have some doubts about storing retrieval specs as pointer values
and evaluating them dynamically whenever the pointer is followed. The
major problem I see is with the back-pointers. E.g., if A has an unevaluated
"support" pointer to "every plan-step whose doer is Keith", then if
I happen to be focusing on some plan-step whose doer is Keith how can
the system efficiently find that A supports that plan-step if I ask
"what items support this plan-step?" I propose, therefore, that
for the present all "indirect" pointer values be evaluated at the
time of storage so that all the explicit pointers and backpointers can
be stored.
Should RETRIEVAL adopt these conventions:
(i) Each POINTER value will be first evaluated before storage.*,**
(ii) Every other value will be simply stored, EXCEPT when that value
is a list whose CAR is EVAL@CREATE,*** in which case, the
rest of that form is handed to the EVAL@CREATE function, which,
for now, we will assume simply EVALs it.
Notes:
* - If you want that value unevaled, just QUOTE it.
** - Using the function EVAL@END-of-CREATE delays the evaluation until
the end of this CreateItems call.
(This facilities forward referencing.)
*** - Perhaps we could define a whole class of these EVAL@←←← operators,
which indicate just when some expression should be evaluated;
and possibly how as well.
Certainly an EVAL@RETRIEVAL is essential; and there may be several
flavors of this, depending on whether the computed value should
replace the current (EVAL@RETRIEVAL ...) expression or not.
Given, my remark above, NO.
--------
Other questions:
I've been scanning the stuff in workbench at Rand-Unix,
and am please to see specifications for the task being solidified.
Shall I assume ENTRY will send me any-and-all of those attributes,
named as such?
(Or perhaps each property name will be in upper case, or ...)
Yes. I believe the syntax of the strings you get from entry will
clearly delimit attribute from attribute value. I don't know about
converting to uppercase, do you need that?
This leads to a whole other can of worms: just what should
RETRIEVAL do when finding a new property? Automatically create a
new unit for this (as I can assume no typos will get by ENTRY),
FALSE. ENTRY will interpret any word (excluding certain reserved words)
as a property name if it is in the right position.
or simply squawk? Perhaps send a query back, to confirm that
attribute is legitimate?
I prefer that third alternative -- with expectations that
ENTRY will then send back some instruction like
YES. The sentiment is that users should be able to create new
pointers or attributes on the fly. I don't like it, but if we
are going to live with it, we need to interact to filter out
typos.
Oops, that was really the Pro attribute, not Por.
Yes, create a new type of POINTER, just like Con. As you
guessed, its inverse is the same name, prefaced with -.
I just asked the user, who told me to forget that attribute.
Comments, please.
Thanks,
Russ
-------
Hope these comments help.
By the way, I currently plan to have all the RLL, ROSIE and IL
processes communicate by reading and writing strings to a
commonly mapped page(s) (emulating IPCF). A top-level executive
process will provide the user access to each sub-process directly.
If a process needs to use another, it will write an addressed
message into the mapped page and return control to the excutive.
The executive will read the address of the message, and activate
the appropriate sub-process, which will take its input from the
mapped page. Any comments on this-- I think it is a common
trick for emulating IPCF.
Keith
∂TO Wescourt, Rick 17:05 24-Jul
(Follow up)↑2
Keith -
------
Exactly. I proposed that the ID's I would be sending you would be local
to the buffer of parsed items sent at any one time. I want to use them
as the values of pointer attributes between those items in the same buffer.
The unique ID you generate will serve the same function for pointers to
items already in the database.
Any thought on how RETRIEVAL should send ENTRY the link -- info to tie
the ENTRY-ID you supply to the UNIQUE-ID I assign.
Maybe something like
(RESPONSE (Entry-Unique <entry-id1> <retr-id1>
<entry-id2> <retr-id2>
... ...
<entry-idN> <retr-idN>))
------
I've begun to have some doubts about storing retrieval specs as pointer values
and evaluating them dynamically whenever the pointer is followed. The
major problem I see is with the back-pointers. E.g., if A has an unevaluated
"support" pointer to "every plan-step whose doer is Keith", then if
I happen to be focusing on some plan-step whose doer is Keith how can
the system efficiently find that A supports that plan-step if I ask
"what items support this plan-step?" I propose, therefore, that
for the present all "indirect" pointer values be evaluated at the
time of storage so that all the explicit pointers and backpointers can
be stored.
I agree -- issues like this complicate retrieval; and mean the obvious retrieval
schemes won't work.
That "every plan-step whose doer is Keith" example seems to force
us (well, me)
to implement demons -- ie little globs of code which act, at item creation
and modification times, doing this dirty work.
I'll gladly push this task until later;
I'd like to first see how often this facility really comes up,
to decide how it should be implemented.
The nice thing about the EVAL@ convention is that it permits us the flexibility
to later on add in things which seem essential --
I will be quite surprised if we can get away with just
storing the unprocessed input value.
<<< Proposal:
Using a form like
(... Sub (EVAL@ AllUpdates
(FindAll (EQ-PROP ITEM-TYPE Plan-Step) (EQ-PROP STATUS IN))) ...)
will both
i) Determine all plan-steps which are in,
storing these as the Sub for this item, I,
and
ii) Set up a demon to monitors the items, noting each time the
status of a plan-step becomes IN.
As this happens, this item is added to I's Sub attribute,
as desired.>>>
[My next message will define retrieval language I used above.]
------
Yes. I believe the syntax of the strings you get from entry will
clearly delimit attribute from attribute value. I don't know about
converting to uppercase, do you need that?
What? My question was about the pre-defined attributes: will you use the same
names which appeared in the note from Barbara, on 16-Jul?
Will you send me AUTHOR rather than CREATOR -- or will be Author, or something
else?
Similarly should RETRIEVAL be prepared for the
Sub, -Sub, Alt, (-Alt), Req, -Req, Cor, Dep, -Dep, Pro, -Pro, Con, -Con
pointers mentioned in that message,
or for SubOrdinate, SuperOrdinate, ...?
or for SUB, -SUB, ...
Similarly will you send me "Type" or Item-Type? And will it now be singular?
Is it STATUSES or STATUS, (or Status)?
We should get together, soon, and decide on these sorts of issues.
(Side Question: Isn't Alt its own inverse? Why have -Alt?)
------
YES. The sentiment is that users should be able to create new
pointers or attributes on the fly. I don't like it, but if we
are going to live with it, we need to interact to filter out
typos.
Ah, this is another thing we should hammer out.
Do you have any suggestions on how RETRIEVAL should ask questions of ENTRY?
ENTRY should also have the option of volunteering information, perhaps using
a CreateItems-like CreateObject command.
This could then be used to define new attributes, pointers, classes, types, ...
------
By the way, I currently plan to have all the RLL, ROSIE and IL
processes communicate by reading and writing strings to a
commonly mapped page(s) (emulating IPCF). A top-level executive
process will provide the user access to each sub-process directly.
If a process needs to use another, it will write an addressed
message into the mapped page and return control to the excutive.
The executive will read the address of the message, and activate
the appropriate sub-process, which will take its input from the
mapped page. Any comments on this-- I think it is a common
trick for emulating IPCF.
The only comment I have is that this method forces us into a single-processor
mode -- there seems no way RLL could be doing some background stuff while
waiting for its next input. But for a level-1 (or are we at 2 yet?) system
this seems quite nice, and sufficient.
------
Russ
∂TO Wescourt, Rick 18:25 24-Jul
Specifications for the Find type of commands:
The command will be
(<Find?> {<spec>})
[{x} means one or more x's]
where <Find?> = FindFirst | FindAll
<spec> = <term> |
(OR {<spec>}) |
(AND {<spec>}) |
(NOT <spec>)
<term> = (EQ-PROP <Prop> <val>) |
(MEMB-PROP <Prop> <val>) |
(SPEC-PROP <Prop> <quant> <spec>) |
(PRED-PROP <Prop> <fn>) |
(PRED <fn>) |
(GEN <sexpr>)
The FindFirst command returns a single UNIQUE-ID - corresponding to the first
and presumably only) item which satisfies these constraints, or NIL.
FindAll returns a list of the UNIQUE-IDs of all items which qualify, or NIL.
Further specification:
<Prop> is any of the attributes, content or pointers,
<val> is an unevaled constant value
(possibly with certain tricks for the unusual case when
you want it evaluated now - probably not)
<fn> evaluates to a predicate function
<sexpr> is a LISP s-expression, to be evaluted,
<quant> = Any | All | None
(If Any, this suceeds when any of the list of values satisfies the predicate, <fn>;
when All, each value must satisfy <fn>,
None means all of the values must fail.
I may later get fancier, and allow numeric ranges, or statements that
as many of these as those, or ...)
Examples:
(EQ-PROP STATUS IN)
(MEMB-PROP KEYWORDS Norm)
(SPEC-PROP Pro Any (EQ-PROP AUTHOR GREINER))
ie refers to an item whose Pro pointer points to some item
whose Author is Greiner.
(PRED-PROP Pro (Either (OneOf (EQ-PROP AUTHOR GREINER))
(AllOf (EQ-PROP STATUS OUT ))))
where
(Either fn1 fn2) = fn3 => [fn3(x) = T] <=> [fn1(x) = T or fn2(x) = T];
(OneOf fn) = fn0 => [fn0(x) = T] <=> [(SOME x fn) = T];
(AllOf fn) = fn0 => [fn0(x) = T] <=> [(EVERY x fn) = T];
[x = T, here, means x is nonNIL]
-- these functions are defined in the system --
Note: EQ-PROP here evaluates to a predicate. I'l say more on that below.
(PRED-PROP Pro '(LAMBDA (val) (OR (> val 7)
(FindFirst (MEMB-PROP SUBJECT Trouble)
(MEMB-PROP TEXT Good)
(EQ-PROP ITEM-TYPE Rationale)))))
Notes: yep, you can call on FindFirst, as you could on any function.
I'll eventually decide on some global variables which will be set
to the UNIQUE-IDs of the current candidates (ie those which qualify
thus far in the query), and maybe some other values as well.
(PRED '(LAMBDA (item) ... ))
this is the ultimate catch-all -- this spec accepts all items which
which satisfy this predicate.
[Before I could say anything meaningful we have to define an attribute
retrieval function -- perhaps simply (GET <item-id> <prop>)...]
(GEN (LIST 'Rat#32))
this is for generating, rather than pruning, possible entries.
Additional notes:
There is an implicit AND-junction of the list of <spec> given
in the <Find?> statement.
------
Nuts and bolts:
The beauty of this system is that
the first 3 types of terms,
(EQ-PROP, MEMB-PROP, and SPEC-PROP)
[and some cases of PRED-PROP as well,]
can be considered as either generators or pruners.
Efficiency comes from deciding which:
Associated with each type of property will be some information
(perhaps simply previously gathered empirical evidence, or maybe some more
elaborate data for some complex symbolic reasoner,) which indicates which
way to determine the qualifying items.
I imagine the eventual algorithm will:
Scan the list of specs, determining which one serves as the best generator.
Execute that, as a generator, to get an initial set.
Subset this generated list using the conjunct of the predicates associated with
each of those remaining specs.
[They should probably first be ordered, so those which
seem most restricted appear first.]
Return that passing list - or its CAR if FindFirst is the caller.
Note that
(1) any GEN will qualify as the Generator, for obvious reasons.
(Actually the intersection of the values of all the GENs...)
(2) Properties which have pre-stored inverses are the next best candidates
for generators -- especially when that inverse is unique.
(3) If nothing even remotely qualifies as a generator, the list of all
items is used. Hopefully this wouldn't happen too often.
(4) Those logical ANDs, ORs and NOTs fit nicely into this sceme, in obvious ways.
Anyway, I wouldn't tire you with more details.
Comments?
Russ
∂TO wescourt at RAND-AI, rick at RAND-AI 14:24 29-Jul
Specification language to Retrieval, from Entry (and anyone else?)
Notation:
{x} means one or more x's
[x] means zero or more x's
(a . b) means (CONS a b)
(a..b) means (APPEND a b)
-- so ((p1 v1)..(p2 v2 p3 v3)) gives (p1 v1 p2 v2 p3 v3)
( and ) are LISP parentheses...
Final preliminary comment: I decided to be arcane, and revert back to
Association Lists, over Property Lists.
They make life so much easier to describe.
Later on, we can upgrade this specification to correspond to that...
ENTRY can send
<Create-Item-Spec> | <Match-Spec> | <Get-Spec> | <Put-Spec>
(and possibly <Create-Obj-Spec> and <Put-Obj-Spec>).
Enter new items
<Create-Item-Spec> ::= (CreateItems {<proplist>}) --0--
<proplist> ::= {<Attribute-val>}
<Attribute-val> ::= <Def-att/val> | <Undef-att/val>
<Def-att/val> ::= --1--
(POINTERS {<ptr-item>})
| (DESCRIPTORS {<Self-desc>})
| (KEYWORDS {<phrase>})
| (HISTORY . (<past-Item-Id-and-reason> <future-Item-Id>))
| (STATUS . <status-val>) --2--
| (TYPE . <type-val>) --3--
| (NAMES . {<phrase>}) --4--
| (TEXT . <sent-string>) --5--
| (SYNTAX . <case-frame-parse>)
<Undef-att/val> ::= (<Undef-att> . <value>)
<Self-desc> ::= --6--
(ENTRY-ID . <Item-Id> ) --7--
| (CREATION-DATE . <creation-date>)
| (AUTHOR . <creator>) --8--
<creation-date> ::= <TIME-STAMP>
<creator> ::= <USER-NAME>
<past-Item-Id-and-reason> ::=
(<Item-Id> <reason-for-change-Item-Id>)
| NIL
<reason-for-change-Item-Id> ::= <Item-Id>
<future-Item-Id> ::= NIL | <Item-Id>
<pointer-val> ::= (<Pointer> . <item-reference-list>)
<Pointer> ::= Sub | -Sub | Req | -Req | Cor | Dep | -Dep
Alt | -Alt --9--
Pro | -Pro | Con | -Con
<item-reference-list> ::=
[<Item-Id>]
| (EVAL@ <time-for-eval> <Match-Spec>) --10--
<time-for-eval> ::= Create | Retrieval | End-Of-Create | Always | AllUpdates
<status-val> ::= IN | OUT
<type-val> ::= REASON | ASSUMPTION | RULE |
MASTER | GOAL | SPECIFICATION | TASK
Still unresolved:
<sent-string>, <phrase>, <case-frame-parse>
Notes
--0-- This function will return, as a confirmation, a list of the form
( (<entry1 . unique1) (<entry2 . unique2) ... (<entryN . uniqueN) )
where each entryI is the value of the ENTRY-ID sent over for some item,
and uniqueI is the UNIQUE-ID Retrieval has assigned this item.
--1-- We will also say
<Def-att/val> ::= (<Def-att> . <value>),
where <Def-att> ::= POINTERS | DESCRIPTORS | KEYWORDS
| HISTORY | STATUS | TYPE | NAMES | TEXT | SYNTAX
--2-- not STATUSes
--3-- not ITEM-TYPES
--4-- What is this for?
--5-- not VERBATIM
--6-- We will say
<Self-desc> ::= (<Self-att> . <value>)
where <Self-att> ::= ENTRY-ID | CREATION-DATE | AUTHOR
(see note --1-- above)
--7-- not UNIQUE-ID -- Only Retrieval can generate UNIQUE-IDs!
--8-- not CREATOR
--9-- Isn't Alt its own inverse?
--10-- This will be defined in the next part.
----------
Find existing items
<Match-Spec> ::= (<Find?> {<spec>})
<Find?> ::= FindFirst | FindAll --0--
<spec> ::= <term>
| (OR {<spec>})
| (AND {<spec>})
| (NOT <spec>)
<term> ::= (EQ-PROP <Prop> <val>)
| (MEMB-PROP <Prop> <val>)
| (SPEC-PROP <Prop> <quant> <spec>)
| (PRED-PROP <Prop> <fn>)
| (PRED <fn>)
| (GEN <sexpr>)
<Prop> ::= <Prim-Prop>
| (Composition {<Prop>}) --1--
| (Unioning {<Prop>})
| (Intersection {<Prop>})
| (Starring <Prop> )
| (Plussing <Prop> )
<Prim-Prop> ::= <Def-att> | <Undef-att> --2--
| <Pointer> | <Self-att> | <Retrieval-att>
<Retrieval-att> ::= UNIQUE-ID
<val> is an unevaled constant value
(possibly with certain tricks for the unusual case when
you want it evaluated now - probably not)
<fn> evaluates to a predicate function
<sexpr> is a LISP s-expression, to be evaluted
<quant> = Any | All | None --3--
NOTES
--0-- The FindFirst command returns a single UNIQUE-ID
-- corresponding to the first (and presumably only) item
which satisfies these constraints, or NIL.
FindAll returns a list of the UNIQUE-IDs of all items which qualify, or NIL.
--1-- These properties are particularly useful for computing ramifications,
needed for the general retrieval mentioned below.
This list of slot combiners is NOT meant to be exhaustive -- but rather
to include the sort of general properties a ramifier might need.
--2-- I'm not sure what will happend with <Undef-att> -- probably
by now they should be defined...
--3-- If Any, this predicate succeeds when any of the list of values
satisfies the predicate, <fn>;
when All, each value must satisfy <fn>,
None means all of the values must fail.
I may later get fancier, and allow numeric ranges, or statements that
as many of these as those, or ...)
----------
Get some property of some item
<Get-Spec> ::= (Get <Item-Id> <Prop>) --0--
| (GetAll <Match-Spec> {<Prop>}) --1--
NOTES
--0-- The Get command returns the value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- GetAll first finds the unit(s) indicated by "evaluating" the <Match-Spec>,
then retrieves the values of their properties.
The value returned is
((Id1 v11 v12 ... v1N) (Id2 v21 v22 ... v2N) ... (IdM vM1 vM2 ... vMN) )
where IdI is the I-th id returned by Match-Spec, and vIJ is the value
of the Jth property mentioned in the {<Prop>} list, of that Ith item.
(If this <Match-Spec> returned only one item, then GetAll pretends it
got the list of that single element.)
Ramification is nothing special now: One can specify the <Prop>
(Starring Sub) - to get all Subs, their Subs, and so on. On
talk about (Composition Sub Alt) - to get all Subs of this item's Alts;
etc.
Below I will discuss how to create new types of properties, defined as some
combination of existing properties.
----------
Modify some property of some item
<Put-Spec> ::= (<Simple-Change> <Item-Id> <Prim-Prop> <value> <Why>) --0--
| (<Mult-Change> <Match-Spec> <Prim-Prop> <value> <Why>) --1--
<Simple-Change> ::= Put | Add | Delete --2--
<Mult-Change> ::= PutAll | AddAll | DeleteAll --3--
<Why> ::= <reason-for-change-Item-Id> --4--
NOTES
--0-- These commands return the new value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- These first finds the unit(s) indicated by "evaluating" the <Match-Spec>,
and then modify the values of their respective <Prim-Prop> properties.
The value returned is
((Id1 v1) (Id2 v2) ... (IdM vM))
where IdI is the I-th id returned by Match-Spec, and vI is the new
value of that property.
(If this <Match-Spec> returned only one item, these functions pretends it
got the list of that single element.)
--2-- Put stores a new value in the <Prim-Prop> property of this item;
Add adds this new value in this property of the item;
and Delete deletes this value in this property of the item.
--3-- The ___All functions do just what the corresponding ___ function did,
but does so to each result of the Match-Spec.
--4-- Why points to an item which tells why this change was made.
----------
Still to do:
1) Hammer out a syntax for defining new properties. Perhaps
(CreateObject <name> ({<slot-val>})), so we might say
(CreateObject Sub* ((Isa . (AnyPointer)) (HighLevelDefn . (Starring Sub))))
-or-
(CreateObject DueDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
[Yes, I know the names seem arbitrary -- we could have a host of aliases
and ways of chopping strings into smaller chunks, if you prefer.]
I'll call this still undefined specification <Create-Obj-Spec>.
Once this is done, we can consider <Put-Obj-Spec>,
and possible <Get-Obj-Spec>.)
2) How to send back and form messages, especially to confirm a new type of object
or slot; and to figure out what to do with it.
Perhaps Retrieval could send something like
(I never heard of "StartDate"; based on the context I assume it is like DueDate,
and so I propose you send back:
(CreateObject StartDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
)
On receiving this, ENTRY could then ask the user what he meant, and
possibly just send back a confirming "Yep", which will serve as if
Entry had sent in that entry; otherwise Entry would be forced to either
retract that last item, or to first send over a new CreateObject statement,
which Retrieval would process before returning to its suspended
offending task.
Retrieval might also send a message like
(Did you mean DueDate when you said DuDate?),
etc.
----------
Comments, suggestions, improvements?
Russ
∂TO Rick@Rand-Ai 13:39 10-Aug
Status
Rick -
This brief status report is in response to my feelings of both delinquency
(at not periodically posting you about my progress) and frustration (read
on). To account for my recent actions: Basically I've been doing general
fix-up and enhancement work to RLL these days -- adding on features which
I believe will make writing the actual retrieval module easier.
I could see little sense writing actual code for this module until many of
the relevant details are tied down. Towards this objective, I've sent
various messages to assorted project members; and am currently awaiting
their respective responses. Included in this list are messages
* to Barbara - 4 June 81
* to Norm - 19 June 81
* to Keith - 24 July 81
* to Keith - 29 July 81
(I think I've CCed you on all of these -- I have retained copies if you'd
like to re-examine any of them...) Anyway, any comments on what else I
should currently be doing?
---Other fronts---
I've prepared, and sorta presented an RLL demo, which I'll be able to show
youse guys my next visit there. Hopefully by then my proto-primer draft
will have matured into a usable document; which I'll, of course, bring
along to distribute.
$$ - To avoid hassles with the Stanford bureaucracy, I have charged Rand
for only one work-day per week all along. In the process, I've accrued an
excess of several days in the process. Unless you object, I'll discharge
(?is that the correct term?) some of these days by submitting bills for
the week of IJCAI and the next "vacation" week. Is that ok?
From the distant backlands of Palo Alto,
Russ
∂10-Aug-81 1650 RICK at RAND-AI Re: Status
To: RDG at SU-AI
cc: RICK at RAND-AI
In-Reply-To: Your message of 10-Aug-81 1339-PDT
Russ:
Yes, it's fine to charge the way you propose. As for waiting on
others, please prompt anybody for any unfilled needs. I'm counting on
using your module real soon (read 5 weeks, since I'll be travelling/
vacating starting in 11 days). I infer that you and Keith should now be
on the verge of integrating working systems. Wednesday, I'll be putting
together the plan for the Sept demo. You and Keith can coordinate on
getting it together in my absence.
Looking forward to putting on a show!
Keep the cards & letters coming.
Rick